[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Fixing merge - Subtree, Cyclic, and Tree Change cases

From: Julian Foad <julian.foad_at_wandisco.com>
Date: Wed, 20 Jul 2011 15:27:02 +0100

Stefan Sperling wrote:
> On Wed, Jul 20, 2011 at 01:13:09PM +0100, Julian Foad wrote:
> > There are (broadly speaking) two ways we could perform a "re-integrate"
> > merge. The "general" way is to do it by using a sufficiently clever
> > general-purpose merge algorithm to merge all the changes that are unique
> > to the branch, onto the trunk. The "special" way is to recognize that,
> > if the branch is up to date with trunk, then the desired state of the
> > trunk is exactly the current state of the branch, so all we need to do
> > is make the trunk look like the branch, which is theoretically a trivial
> > operation.
[...]
> I think the above description simplifies things a bit too much
> for the purpose of this discussion.
[...]
> A re-integrate does not simply swap out the trunk with the branch.
> It runs a two-URL merge with parameters constructed in such a
> way that the delta being merged contains exactly the changes
> committed for the feature, and no unrelated changes.
[...]
> feature +-------------------------------R
> / . \
> / .............. \
> / . v
> trunk ------+--------------------L------------------o
> rW rX
>
> In the diagram above, L marks the left side of the merge (trunk_at_X),
> and R marks the right side of the merge (feature_at_HEAD). The difference
> between the left and right side is merged into the target.

Ah... I didn't realize it is that flexible. Thanks for correcting me.
That's very useful for anyone trying to re-integrate onto a "busy"
trunk.

> > Note that a practical benefit of the work flow using the "special"
> > re-integrate is it ensures the reintegration will not generate any merge
> > conflicts - neither physical, nor semantic (since we assume the branch
> > has been reviewed and tested).
>
> It does not generate conflicts because of the way REV1 is chosen,
> and because of the way PATH1 and PATH2 are chosen.

In fact, this must imply that you *can* get conflicts if any of the
changes on trunk after rX conflicts with the "feature". But the
recommended work flow would be to do the last "catch-up" (which defines
X) just before the re-integrate, so the opportunity for such conflicts
would be small.

- Julian
Received on 2011-07-20 16:27:41 CEST

This is an archived mail posted to the Subversion Dev mailing list.