On Fri, Jan 22, 2010 at 05:52:24PM -0500, Bob Archer wrote:
> > I am encountering an issue with "svn merge --reintegrate" when doing
> > round-trip branch-trunk merges. Yes, I know these are problematic, but we
> > don't have problems with them except for this one case.
> >
> > The general scenario is:
> > 1. Create a new file on the branch.
> > 2. svn merge --reintegrate to the trunk.
> > 3. Modify the file on the branch.
> > 4. svn merge --reintegrate to the trunk.
> >
> > The second merge will raise the file as a tree-conflict: "local add,
> > incoming add upon merge".
> >
> > If a --record-only trunk-to-branch merge is done of the revision created
> > by step #2 above, this tree-conflict is avoided. (We normally do this kind
> > of record-only merge only when merging trunk changes to the branch and not
> > in this scenario).
> >
> > "svn merge ^/trunk ^/branch" for step #4 doesn't have this problem. (I
> > find this interesting, but perhaps it's perfectly logical.)
It does not have this problem because you are using ^/trunk_at_HEAD
(@HEAD is the default), not ^/trunk@{revision in which the branch
was last synced with trunk}.
The latter is what --reintegrate really does. It's a special 2-URL merge
which also figures out the proper peg revision to use for the merge
source URL (^/trunk in this example).
> >
> > I see this behavior with both 1.6.6 and 1.6.9. Is this a bug?
> >
> > I've attached a script that reproduces the scenario.
>
> I'm pretty sure this is totally expected and by design. The record
> only merge to trunk is the recommend way to continue using a branch
> that you have re-integrated. (other than deleting the branch).
Yes. The --record-only merge, and a sync merge from trunk to
the branch, must always be done before reintegrating the same
branch again to avoid spurious conflicts caused by changes
being merged a second time.
Deleting and re-creating the branch has the same effect.
Stefan
Received on 2010-01-23 01:00:50 CET