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
Received on Sat May 29 02:09:50 2004