Re: Merging Branches

This is a good methodology when you can bring in all changes from X+1 to HEAD. I'll have to remember that and put it in my agency's documentation.

Not sure who you were replying to, but Russ's original message that started this thread stated he cherry picked some important fixes from the trunk and merged them in to his branch. As Ben commented earlier, in this situation remembering which revisions were merged and which weren't is much more complicated.

While I think it would be beneficial to implement a partial trunk to branch merge strategy for the simple case you outlined(and ignore the more complicated cherry picking and other situations), it's probably not that simple either. There's other use cases that would have to be considered that make it more complicated such as failing if you merge in a revision outside the block and "re-allowing" if you revert those revisions back, etc.

Of course, I'm pretty much talking out my ... since I've been playing with subversion for all of 2 days and have now given this 2 minutes of thought. :)

Bob

>>> "Patrick Dean Rusk" <PRusk@foliage.com> 09/03/04 02:25PM >>>
Your situation is actually far easier to resolve than you might think.

I personally think the "right way" described in the Subversion book does not
work well at all for branches that last more than a couple days in an active
repository. It envisions that you branch, do work on that branch without
ever bringing over changes from the trunk, then merge your branch changes
back in.

My experience has been that branches need to periodically bring over changes
made to trunk, as you have experienced. So, here's what I've found to work
well:

1) Cut your branch, noting the revision of the branch point, say "X".

2) After some time, merge revisions X+1 to HEAD into the branch. Note the
revision of HEAD, because that becomes your new "X". Your branch is
effectively now a branch from HEAD whose only difference is whatever changes
you made in the branch.

3) Keep doing step 2 until you're done with your branch changes.

4) Do step 2 one more time, so that you branch is completely up-to-date with
trunk's HEAD.

5) Now you merge the branch into trunk without any reference to revisions or
ranges at all. You're effectively replacing trunk's HEAD with the branch
HEAD. That's exactly what you want, because your branch now represents
(trunk + branch changes).

6) Do a check to make sure that no one snuck in another trunk revision
between 4 and 5. If so, you may need to merge that change into trunk.

I used this strategy in a 2500 file project where my branch affected 500+
files over a 5 week period. It worked perfectly.

Patrick Rusk

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Sep 3 22:09:48 2004