> From: leojhartiv [mailto:leo.hart_at_gmail.com]
> Sent: Saturday, February 18, 2012 8:36 AM
> To: users_at_subversion.apache.org
> Subject: Branching/Merging Strategy
>
> I wanted to describe our branching and merging strategy and hopefully get some feedback. We are using Subversion Server 1.6.
>
> Currently we manage trunk plus up to 3 other branches:
> * trunk: always represents "what's in production"
> * 1.0.0, 2.0.0, etc: represent long-term (normally quarterly) development branches
> * 1.1.0, 1.2.0, etc: represent monthly maintenance branches
> * 1.0.1, 1.0.2, etc: represent "deploy immediately" hot fix branches
> Our process of creating a branch is to svn copy from trunk into the new branch. So in the case of a new development branch:
> svn copy "http://myrepos/trunk" "http://myrepos/branches/2.0.0"
> Or in the case of a new maintenance branch:
> svn copy "http://myrepos/trunk" "http://myrepos/branches/1.1.0"
> When either branch has been deployed to production, we use a svn merge reintegrate to merge it back into trunk. So in the case of the maintenance branch:
> svn --accept p merge --reintegrate "http://myrepos/branches/1.1.0" "http://myrepos/trunk"
> We then merge trunk into any future releases still pending and resolve any conflicts:
> svn merge "http://myrepos/trunk" "http://myrepos/branches/2.0.0"
> This has worked well in most instances. The reintegrate option almost never has any conflicts. However, when we got close to deploying 2.0.0 we ran into trouble.
> 1 or 2 weeks before we were ready to launch 2.0.0, some of the team needed to start work on 2.1.0 and 3.0.0 while others were finishing up on 2.0.0. The normal process would be to create 2 branches off trunk:
> svn copy "http://myrepos/trunk" "http://myrepos/branches/2.1.0"
> svn copy "http://myrepos/trunk" "http://myrepos/branches/3.0.0"
> Unfortunately, this won't really work as much of the work on these branches depends on completed work currently in 2.0.0, but not yet merged to trunk (since we haven't gone to production yet).
> So what we did was create these branches off of 2.0.0:
> svn copy "http://myrepos/branches/2.0.0" "http://myrepos/branches/2.1.0"
> svn copy "http://myrepos/branches/2.0.0" "http://myrepos/branches/3.0.0"
> This worked fine until we started reintegrating 2.0.0 back into trunk and out to 2.1.0 and 3.0.0. We've found that all of our merges are missing change-sets and often report conflicts that don't really exist. My guess is that branching off of 2.0.0 has confused subversion's automatic merge tracking, but I honestly don't understand how all of that works enough to be sure.
>
> My questions are:
> * How are other teams handling the above scenario?
> * Is there a different approach we should be using?
> Thanks for your help!
The merge problems you describe (synching trunk to 2.1.0) can be done correctly, but they are harder to get correct. You need someone who really understands branching and 2-URL merging. I often have to draw the branches on a whiteboard and identify the ranges/deltas that need to be merged.
That being said, your branch strategy may be making it harder than it needs to be. Many times multiple versions of software may be in production or supported at a time, rather than a single version in production. A common pattern is that the trunk is for new feature development, and then released software is branched off. Any fixes/patches go on the side branch and also merged back to trunk for future releases.
-Steve
Received on 2012-02-19 19:34:55 CET