Subversion Cookbook - Advice and Best Practices on Branching and Merging

[Mark Phippard <Ma...@softlanding.com>]

I am looking for some recommendations on branch creation and merging in a 
repository.  The scenario is a software product that has regular releases, 
as well as ongoing maintenance, and also the software can be heavily 
customized for specific customers.  I was thinking of a layout like this:

Project
 |--- Trunk
 |--- Tags
      |---R1.0
      |---R1.1
      |---R2.0
 |--- Maintenance
      |---R1.0
      |---R1.1
      |---R2.0
 |--- CustomerMods
      |---CustomerA
      |---CustomerB
      |---CustomerC

New development would be performed on the Trunk.  At some point a release 
branch would be created and development would continue on that branch 
until the release was finalized, at which point a Tag would be created 
from that branch.  Future maintenance would continue on that branch, and 
changes would be merged back to the trunk as appropriate. 

This part seems fairly straightforward, although it seems that Subversion 
does its own development primarily on Trunk and Release branches are made 
by cherry-picking specific changes off the trunk and merging them to the 
branch.  Are there any technical reasons that method works better, or does 
it just work better for this project and the way it is developed?

Customer Mods:
Logically, what makes most sense to me would be to create the branch by 
copying the release Tag for the release that the Mods will be started 
from.  However, I wonder if this has any impact on later merges?  When a 
customer is going to be moved from R1.0 to R1.1 or R2.0 I would expect to 
want to merge their branch with the changes in that branch, or the 
corresponding release tag.  Can that be done?  I am a little concerned 
about whether Subversion would be able to discern the proper ancestry in 
that scenario?

Should all copies and merges be based on Trunk to avoid that problem?  On 
the surface, that just sounds a little more difficult and less logical to 
manage and keep track of.  I am hoping some of you out there that have 
been through a similar process already with Subversion and can offer some 
guidance.

By the way, I am wondering if anyone is thinking about or working on a 
"Subversion Cookbook"?  It would be nice to see some of these scenarios 
talked through with real command examples.  For example, I would love to 
have a better understanding as to how the Subversion 1.0.x releases are 
created and how the merges are handled.  I have some idea by watching the 
discussions that take place but it would be interesting to see what the 
series of Subversion commands are that need to be run and what sort of 
problems arise in merging in changes.

Thanks

Mark 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Subversion Cookbook - Advice and Best Practices on Branching and Merging

[Mark Phippard <Ma...@softlanding.com>]

Ben Collins-Sussman <su...@collab.net> wrote on 05/29/2004 09:22:47 AM:

> Mark Phippard wrote:
> 
> > By the way, I am wondering if anyone is thinking about or working on a 

> > "Subversion Cookbook"? 
> 
> Have you seen this?  Especially the last section on branching policies?
> 
> http://svn.collab.net/repos/svn/trunk/doc/user/svn-best-practices.html
> 
> 

I hadn't, I will take a look.

I also re-read Chapter 4 last night after I posted the message.  It 
actually addresses a lot of my concerns a lot better than I had originally 
thought.  I still think my main concern is that in the scenario I proposed 
there will be many "permanent" branches, and over time those branches will 
seemingly need to merge changes from different sources.  I am sure that 
Subversion handles it, I would just love to see it spelled out more.

For example, suppose that the R1.0 maintenance branch and tag are made off 
Trunk revision 10.  Sometime later, I get a CustomerA that I am going to 
do Mods of R1.0 for.  Do I copy the tag to create their branch, or do I 
have to re-copy Trunk at revision 10.  Also, let's assume that the HEAD of 
trunk is now at 40 when I do the copy.

I make a bunch of mods for the customer and ship them. 

At revision 60 a R2.0 branch is started and at R64 an R2.0 tag is made 
when the release is finished.

So, back to my CustomerA mods, how do I catch them up to R2.0?  Perhaps by 
merging with the R2.0 tag and specifying --ignore-ancestry? 

If I used the R2.0 branch as a reference wouldn't it only know about the 
changes made between r60:64?  Could I use the R2.0 branch and specify 
r10:64?  I suppose I could since the copy will follow history back before 
the copy.

Just thinking out loud, does the process become more complicated as we 
progress to R3.0 and R4.0 or is it just the same basic steps over and over 
again?  I think it is the latter.  Anyway, I will probably try to simulate 
it all next week so I can see for myself.

Mark




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Subversion Cookbook - Advice and Best Practices on Branching and Merging

[Ben Collins-Sussman <su...@collab.net>]

Mark Phippard wrote:

> By the way, I am wondering if anyone is thinking about or working on a 
> "Subversion Cookbook"? 

Have you seen this?  Especially the last section on branching policies?

http://svn.collab.net/repos/svn/trunk/doc/user/svn-best-practices.html



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org