RE: Branching/Merging Strategy

Thanks for your responses!

I guess the part I'm missing is how you would support hotfixes, etc? If I
don't always branch off of trunk (production), how can I be sure I'm only
releasing the small changes to support the hotfix, versus all the other
changes being worked on for a larger development release?

Varnau, Steve (Neoview) wrote:
>
>> -----Original Message-----
>> From: John Maher [mailto:JohnM_at_rotair.com]
>> Sent: Monday, February 20, 2012 5:37 AM
>> To: Varnau, Steve (Seaquest R&D)
>> Subject: RE: Branching/Merging Strategy
>>
>>
>> Hello
>>
>> I'm new to subversion and have two questions.
>>
>> 1) How do I properly make a post? I get these e-mails but no where do
>> I see any information on how to put a post up.
>
> Just mail to users_at_subversion.apache.org. I've copied the list on this
> response.
>
>>
>> 2) I had a problem with a merge where code from one function had gotten
>> placed in another along with all kinds of other problems to the point
>> where I do not feel comfortable with the merge. It took a week going
>> through backups to fix the code. I would like to learn how to use it
>> without problems but something in the statement confused me. The
>> statement "A common pattern is that the trunk is for new feature
>> development" doesn't make much difference between using the trunk for
>> production and branches for future releases if the trunk and branch are
>> just labels that have no meaning. Or is there some hidden meaning that
>> I do not know about?
>
> The naming does not really matter. In my project, what we treat as our
> trunk is not really named "trunk". But that is the common terminology used
> in the list.
>
> The pattern of usage is the key thing, not the names. So one place where
> all the changes get integrated back together into a common source tree is
> the logical trunk, whether we call it trunk, branch/main, or bob.
>
> The original poster is using a pattern where the trunk is what is in
> "production". So when a feature is ready to go into production, they merge
> it in. I am suggesting that a more common method is the reverse -- when
> something is ready for production, branch it off.
>
> For instance, the subversion software itself has to support old releases
> that are in the field, not just one "production" version. So, features
> are developed on the trunk and when getting ready to release, they create
> a release branch. Fixes can be made on those branches, released, and also
> merged back to trunk for future releases. But the trunk is never synched
> (merged) back to those release branches.
>
> So in this model, there is a main line of development (trunk), and two
> kinds of side branches. Release branches and development branches. As I
> described above, release branches are not synched up to the trunk, but
> development branches are synched before they are reintegrated.
>
> Nothing magic in the naming, and subversion does not keep track of which
> branches are what types. It is just in the merging patterns used. You are
> left to keep track of that by naming schemes, etc.
>
>>
>> Thanks
>> Mar
>
> Hope that helps.
> -Steve
>
>> -----Original Message-----
>> From: Varnau, Steve (Seaquest R&D) [mailto:steve.varnau_at_hp.com]
>> Sent: Sunday, February 19, 2012 1:34 PM
>> To: leojhartiv; users_at_subversion.apache.org
>> Subject: RE: Branching/Merging Strategy
>>
>> > 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
>
>

-- 
View this message in context: http://old.nabble.com/Branching-Merging-Strategy-tp33348661p33365655.html
Sent from the Subversion Users mailing list archive at Nabble.com.