Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm about to start work on a new version (version 4) of my commercial application. I use Subversion.

Based on your experiences, mistakes, and successes, how would you recommend I set up the new version in Subversion?

Here's some info: I intend to keep releasing critical updates in version 3 for some time after version 4 is released. However all development of new features will be solely in version 4.

In case it is relevant: I'm a solo developer on this product, and that is likely to remain the case.

EDIT: I'm aware of SVN's tags and branches. I guess what I need is an optimal strategy for using tags and branches in my situation.

share|improve this question
add comment

4 Answers 4

What you are asking about is the branch (and merge) strategy to use. So take the post of karthik t and take that as a recipe.

For some background, read the following resources:

share|improve this answer
add comment

I found an excellent guide to this situation:

If you want to be able to both develop a newer version (in trunk) and 
fix bugs on an older version, what you want is a branch for the older 
version. You can fix your bug in the older version's branch, then 
make a new tag of that. 
Example: 
/repo/ 
        project/ 
                trunk/ 
                branches/   
                tags/ 
You've developed your software in trunk and are now ready to call it 
version 1.0. You make a branch and a tag: 
svn cp $REPO/project/trunk $REPO/project/branches/1.x 
svn cp $REPO/project/branches/1.x $REPO/project/tags/1.0 
/repo/ 
        project/ 
                trunk/ 
                branches/ 
                        1.x/    
                tags/ 
                        1.0/ 
Now you continue to develop in trunk, adding new features, and this 
will eventually become version 2.0. But while you're doing this, you 
find a bug in 1.0 and need to fix it quick. So you check out branches/ 
1.x, make the change, test it, and commit it. Then you tag that as 1.1: 
svn cp $REPO/project/branches/1.x $REPO/project/tags/1.1 
/repo/ 
        project/ 
                trunk/ 
                branches/ 
                        1.x/    
                tags/ 
                        1.0/ 
                        1.1/ 
If the bug also exists in trunk, then you need to port your bugfix to 
trunk. "svn merge" can help you there. 
cd trunk-wc 
svn merge -c$R $REPO/project/branches/1.x . 
where $R is the revision in which you fixed the bug on the 1.x 
branch. Now you test the fix in trunk and then commit it. Now the bug 
is fixed in trunk too. 
share|improve this answer
add comment

It depends.

You can keep version 4 in the trunk and continue developing on V4. Version 3 would be a branch, that you'd update as needed. The benefit of this approach is if a critical issue was discovered in V3 that is also in V4, you could do a simple merge on the file(s) across the branches.

The other option is to create and entirely new repository for V4. This will give you a fresh start. The downside is the change history is reset and you will not be able to merge files via Subversion. You'll have to use a program such as Beyond Compare to merge in changes.

Personally I would stick with the first approach. Create a V3 branch and maintain the code and the updates in this branch. The new V4 code can be developed in the trunk.

share|improve this answer
add comment

What you want to do is create Branches. It is as it sounds a branch in your source tree, typically a copy of your source when you release it. You would commit into this branch for the critical updates, and build the update from this branch.

What you are commiting into right now would be the trunk and you would code version 4 in there. If any major changes are commited to version 3, and you would like to have it in version 4, you would do a merge from the branch (v3) to the trunk(v4) to bring the changes over to the trunk.

You can also look at tags, which are like branches but link to a single version, typically the last revision of a version (or the first).

share|improve this answer
    
While making a branch of the previous version, you can also create a tag for every update/release you create. This way you have a branch to commit to, and you can use the tags to build any previous release you made. –  Geerten Dec 7 '12 at 8:24
    
IIRC tags in svn do not necessarily link to single versions, they are in fact identical to branches in all but intension –  jk. Dec 7 '12 at 9:00
    
Actually, branches and tags are identical in implementation, they are essentially copies of the code. It is only in convention that they differ, tags are intended to point to a particular revision, while branch is supposed to be a alternate development path. –  Karthik T Dec 7 '12 at 9:01
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.