[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Branching/Merging Strategy

From: leojhartiv <leo.hart_at_gmail.com>
Date: Sat, 18 Feb 2012 08:35:52 -0800 (PST)

I wanted to describe our branching and merging strategy and hopefully get
some feedback.&nbsp; We are using Subversion Server 1.6.

Currently we manage trunk plus up to 3 other branches:

trunk:&nbsp; always represents &quot;what's in production&quot;
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 &quot;deploy
        immediately&quot; hot fix branches

Our process of creating a branch is to svn copy from trunk into the new
branch.&nbsp; So in the case of a new development branch:

svn copy &quot; http://myrepos/trunk http://myrepos/trunk &quot; &quot;
http://myrepos/branches/2.0.0 http://myrepos/branches/2.0.0 &quot;

Or in the case of a new maintenance branch:

svn copy &quot; http://myrepos/trunk http://myrepos/trunk &quot; &quot;
http://myrepos/branches/2.0.0 http://myrepos/branches/1.1.0 &quot;

When either branch has been deployed to production, we use a svn merge
reintegrate to merge it back into trunk.&nbsp; So in the case of the

svn --accept p merge --reintegrate &quot; http://myrepos/branches/2.0.0
http://myrepos/branches/1.1.0 &quot;
        &quot; http://myrepos/trunk http://myrepos/trunk &quot;

We then merge trunk into any future releases still pending and resolve any

svn merge &quot; http://myrepos/trunk http://myrepos/trunk &quot; &quot;
http://myrepos/branches/2.0.0 http://myrepos/branches/2.0.0 &quot;

This has worked well in most instances.&nbsp; The reintegrate option almost
never has any conflicts.&nbsp; However, when we got close to deploying 2.0.0
ran into trouble.&nbsp;

1 or 2 weeks before we were ready to launch 2.0.0, some of the team needed
start work on 2.1.0 and 3.0.0 while others were finishing up on 2.0.0.&nbsp;
normal process would be to create 2 branches off trunk:

svn copy &quot; http://myrepos/trunk http://myrepos/trunk &quot; &quot;
http://myrepos/branches/2.1.0 http://myrepos/branches/2.1.0 &quot;

        svn copy &quot; http://myrepos/trunk http://myrepos/trunk &quot; &quot;
http://myrepos/branches/3.0.0 http://myrepos/branches/3.0.0 &quot;

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
we haven't gone to production yet).

So what we did was create these branches off of 2.0.0:

svn copy &quot; http://myrepos/trunk http://myrepos/branches/2.0.0 &quot;
        &quot; http://myrepos/branches/2.1.0 http://myrepos/branches/2.1.0 &quot;

        svn copy &quot; http://myrepos/trunk http://myrepos/branches/2.0.0 &quot;
        &quot; http://myrepos/branches/3.0.0 http://myrepos/branches/3.0.0 &quot;

This worked fine until we started reintegrating 2.0.0 back into trunk and
to 2.1.0 and 3.0.0.&nbsp; We've found that all of our merges are missing
change-sets and often report conflicts that don't really exist.&nbsp; My
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

My questions are:

How are other teams handling the above scenario?
Is there a different approach we should be using?&nbsp;

Thanks for your help!

View this message in context: http://old.nabble.com/Branching-Merging-Strategy-tp33348661p33348661.html
Sent from the Subversion Users mailing list archive at Nabble.com.
Received on 2012-02-18 17:36:26 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.