You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Russ Brown <su...@dot4dot.plus.com> on 2004/09/03 14:11:05 UTC
Merging Branches
Hello,
My company is considering switching from CVS to Subversion, so I'm
currently evaluating Subversion by using it at home for personal projects.
In particular we're interested in the branching capabilities, so although
there's only me involved at the moment I've been using branches for the
larger bits of work I'm doing so I can get a feel for how it works.
So far I've successfully done things like this:
1. Create branch at revision 12.
2. Work on branch.
3. Merge branch into trunk.
I'm also happy with the situation where I do more work on the branch and
merge the branch into the trunk again: no problems there.
The problem I have right now is a situation where I've been doing a rather
larger bit of work on a branch, and along the way I've made some smaller
fixes on the trunk. Because these have been important fixes I've merged
the trunk into the branch after committing these changes to trunk so my
branch can be developed with these fixes already in place.
That's all been fine, and I've done this about 3 times (on one occasion
the additional work was done on another branch, merged into trunk and then
merged into my 'big branch'). The problem is that I'm now in a situation
where the work on the branch is finished and I want to merge it into the
trunk .The thing that confuses me is that he branch now contains changes
that are already in the trunk, which for me could confuse Subversion and
cause a horrible mess.
The way I see it, there are two possible ways in which this should work:
1. Merge the revisions between the revisions that were merged from trunk
to branch, so I've have to do a sequence of merges to get it to work. For
example, if I merged trunk to branch at revisions 10, 15 and 20 (with the
branch created at 5), I'd have to merge something like 6:9, 11:14, 16:19,
21:HEAD
2. Merge all revisions of the branch from the time the branch was created
(or the last time it was merged to trunk if that is the case) right
through to head. (i.e. 6:HEAD).
1. seems like a lot of work to me, and 2 'feels' like it will break. So is
there another method I'm missing or is one of these the Right Way?
Thanks for your time.
--
Russell Brown
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging Branches
Posted by Scott Palmer <sc...@2connected.org>.
On Sep 3, 2004, at 12:33 PM, Ben Collins-Sussman wrote:
> On Fri, 2004-09-03 at 11:24, Scott Palmer wrote:
>
>> Is it really that hard? Isn't this a fairly simple extension of what
>> is already in place? always remember the version at which the code
>> branched or was merged. When a merge is done update a "merge-point"
>> record that says 'changes prior to this point are already merged'.
>> Subsequent merges would only merge changes from the last
>> "merge-point".
>> Is it really 2 years to do that feature? Or am I way
>> over-simplifying
>> like I usually do :) ?
>
> You've described a simple solution for the case where you repeatedly
> merge contigous ranges of revisions from one branch to another. It
> solves the problem of the user asking, "hm, where did that last merge
> end? Let me pick up from there."
>
> But in your own case, you've done 'cherry-picking'. You've selectively
> ported a bunch of random, non-contiguous changesets. Now you want to
> merge the "whole branch" to another, and not repeat changesets you've
> already got. Much more complicated.
>
> Take a look at the Arch and SVK homepages. There are volumes of
> philosophy dedicated to solving this problem.
Point taken, I guess the "simple case" is all I've ever needed.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging Branches
Posted by Ben Collins-Sussman <su...@collab.net>.
On Fri, 2004-09-03 at 11:24, Scott Palmer wrote:
> Is it really that hard? Isn't this a fairly simple extension of what
> is already in place? always remember the version at which the code
> branched or was merged. When a merge is done update a "merge-point"
> record that says 'changes prior to this point are already merged'.
> Subsequent merges would only merge changes from the last "merge-point".
> Is it really 2 years to do that feature? Or am I way over-simplifying
> like I usually do :) ?
You've described a simple solution for the case where you repeatedly
merge contigous ranges of revisions from one branch to another. It
solves the problem of the user asking, "hm, where did that last merge
end? Let me pick up from there."
But in your own case, you've done 'cherry-picking'. You've selectively
ported a bunch of random, non-contiguous changesets. Now you want to
merge the "whole branch" to another, and not repeat changesets you've
already got. Much more complicated.
Take a look at the Arch and SVK homepages. There are volumes of
philosophy dedicated to solving this problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging Branches
Posted by Scott Palmer <sc...@2connected.org>.
On Sep 3, 2004, at 11:49 AM, Ben Collins-Sussman wrote:
> Yes, there are absolutely plans to add this feature. Come back in a
> year, and see how far we are. We're going to get reserved checkouts
> (locking) done first. "Merge tracking" is a phrase that could apply to
> a dozen different problems, and this is just one of them. It's a
> tremendous task to design and implement.
>
> FWIW, CVS dosen't have merge-tracking either. But we decided it was
> better to release Subversion 1.0 after 4 years (with the advantages it
> *does* have over CVS) rather than wait another 2 years to add
> merge-tracking. :-)
>
Is it really that hard? Isn't this a fairly simple extension of what
is already in place? always remember the version at which the code
branched or was merged. When a merge is done update a "merge-point"
record that says 'changes prior to this point are already merged'.
Subsequent merges would only merge changes from the last "merge-point".
Is it really 2 years to do that feature? Or am I way over-simplifying
like I usually do :) ?
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging Branches
Posted by Ben Collins-Sussman <su...@collab.net>.
I don't think you meant to send this reply to me personally. Resending
back to users@.
On Fri, 2004-09-03 at 10:31, Russ Brown wrote:
> To answer two posts at the same time...
>
> On Fri, 03 Sep 2004 09:51:54 -0500, Ben Collins-Sussman
> <su...@collab.net> wrote:
>
> > On Fri, 2004-09-03 at 09:47, Jacob Atzen wrote:
> >
> >> I'm no expert but it seems like your suggestion number 1 is "The Right
> >> Way"(tm). I assume you've read the books chapter on merging?
> >>
> >> <http://svnbook.red-bean.com/svnbook/ch04s03.html>
> >>
>
> Yes I did, but as is often the case the chapter provides plenty of
> information on the more simple use cases but not on the more complex cases
> that tend to cause me to turn to the manual. :-)
>
> >> Your number 2 might work if you haven't changed the lines containing
> >> your trunk to branch merges:
> >>
> >> When patching a file, Subversion typically notices if the file
> >> already has the change, and does nothing.
> >
> > Congrats, Russ. You've just discovered why Subversion really needs a
> > merge-tracking feature. :-)
> >
> > If Subversion were anything like clearcase, you'd simply say, "hey,
> > please merge my branch back into trunk", and the system would
> > automatically know which changes already existed in both branch and
> > trunk, and skip over them for you.
> >
>
> Well, I tried them both.
>
> 1. Was indeed a nightmare, and I ended up with a whole load of conflicts
> to deal with. I tried reverting the WC and ended up with one that wouldn't
> even let me do svn info. Not good!
> 2. Actually worked ok. I had a few conflicts, but nothing that I'd call a
> nightmare.
>
> So in this case it worked out ok, but in a situation with many developers
> working on separate branches merging to trunk and back, a similar
> situation will arise often and may not be so easily dealt with.
>
> Are there any plans to add a merge tracking feature to Subversion, and if
> so is there a planned version that it might appear in? From my evaluations
> so far this is the only aspect of Subversion that I have doubts about:
> everything else appears to be just what we're looking for (I did try arch
> for a while before this but got frustrated with weird conventions, lack of
> useful documentation and the attitudes of some of the developers).
Yes, there are absolutely plans to add this feature. Come back in a
year, and see how far we are. We're going to get reserved checkouts
(locking) done first. "Merge tracking" is a phrase that could apply to
a dozen different problems, and this is just one of them. It's a
tremendous task to design and implement.
FWIW, CVS dosen't have merge-tracking either. But we decided it was
better to release Subversion 1.0 after 4 years (with the advantages it
*does* have over CVS) rather than wait another 2 years to add
merge-tracking. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging Branches
Posted by Ben Collins-Sussman <su...@collab.net>.
On Fri, 2004-09-03 at 09:47, Jacob Atzen wrote:
> I'm no expert but it seems like your suggestion number 1 is "The Right
> Way"(tm). I assume you've read the books chapter on merging?
>
> <http://svnbook.red-bean.com/svnbook/ch04s03.html>
>
> Your number 2 might work if you haven't changed the lines containing
> your trunk to branch merges:
>
> When patching a file, Subversion typically notices if the file
> already has the change, and does nothing.
Congrats, Russ. You've just discovered why Subversion really needs a
merge-tracking feature. :-)
If Subversion were anything like clearcase, you'd simply say, "hey,
please merge my branch back into trunk", and the system would
automatically know which changes already existed in both branch and
trunk, and skip over them for you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging Branches
Posted by Jacob Atzen <ja...@aub.dk>.
On Fri, Sep 03, 2004 at 03:11:05PM +0100, Russ Brown wrote:
> The way I see it, there are two possible ways in which this should work:
>
> 1. Merge the revisions between the revisions that were merged from trunk
> to branch, so I've have to do a sequence of merges to get it to work. For
> example, if I merged trunk to branch at revisions 10, 15 and 20 (with the
> branch created at 5), I'd have to merge something like 6:9, 11:14, 16:19,
> 21:HEAD
> 2. Merge all revisions of the branch from the time the branch was created
> (or the last time it was merged to trunk if that is the case) right
> through to head. (i.e. 6:HEAD).
>
> 1. seems like a lot of work to me, and 2 'feels' like it will break. So is
> there another method I'm missing or is one of these the Right Way?
I'm no expert but it seems like your suggestion number 1 is "The Right
Way"(tm). I assume you've read the books chapter on merging?
<http://svnbook.red-bean.com/svnbook/ch04s03.html>
Your number 2 might work if you haven't changed the lines containing
your trunk to branch merges:
When patching a file, Subversion typically notices if the file
already has the change, and does nothing.
--
Cheers,
- Jacob Atzen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merging Branches
Posted by Patrick Dean Rusk <PR...@foliage.com>.
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