RE: Branching/Merging Strategy

As a follow-up, strategy #2 seems to describe what my team is doing:
http://blogs.collab.net/subversion/2007/11/branching-strat/

leojhartiv wrote:
>
> 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-tp33348661p33366451.html
Sent from the Subversion Users mailing list archive at Nabble.com.