RE: Question about merging and branch management
From: marlene cote <mcote_at_juniper.net>
Date: Wed, 28 Oct 2009 10:44:19 -0400
Todd,
---------------------
-----Original Message-----
> -----Original Message-----
I think the second is less effort to maintain, but you do have to switch your developers over to the new branch each time you do this. Also, I expect you'll see that the history looks a little weird, because if you make a change in branch A, and merge it to branches B, then C, then D, then E, and then finally back to trunk, then what you're going to see in the trunk, even when you show the merged revisions, may not be so helpful. The trunk just has E's merge, part of which was the merge from D, part of which was the merge from C...all the way back to A.
The down sides with merging repeatedly from the trunk to a branch are the time to merge, plus all the changed files, which will bloat the repository prior to version 1.6 ( see http://subversion.tigris.org/svn_1.6_releasenotes.html#rep-sharing ).
Personally, with a 1.6 repository I would tend towards repeatedly merging to the branch rather than creating a new branch. I would only go to a new branch after merging all of that branch's changes to the trunk. But there's certainly room for personal preference.
--Todd
------------------------------------------------------
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
|
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.