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

Re: Subversion Patch for multiple tree-conflicts during merge

From: Neels Janosch Hofmeyr <neels_at_elego.de>
Date: Sun, 21 Jun 2009 00:09:09 +0200

patric_at_rufflar.de wrote:
> Hello Neels,
> I followed your postings on the SVN dev mailing list according the thread
> "Re: multiple tree-conflicts during merge -- was: Re: Error reading
> spooled REPORT request response"
> It seems I am also experiencing this kind of bug, using svn+ssh://
> protocol, but doing a single commit merge (using -c parameter).
> My question is if your patch will be part of the forthcoming 1.6.3
> release of Subversion.
> Beside that, is there any way to workaround this bug in my case (single
> commit merge)?
> Thanks in advance!
> Best Regards,
> Patric Rufflar

Hi Patric,

the problem I was fixing is this:

other branch: _/----existed----D (did not exist) A----re-added
this branch: \-----------------(modified and stuff)-------------
                              (merging top onto bottom)
The modification can be a) in the local working copy, uncommitted, or b)
committed on a branch that has a common ancestor.

You'd also hit this if the D and A happened in the same commit (*R*eplace).

The problem is that the tree-conflicts detection first handles the D and
then the A, separately, and finds both of them conflicting with a local
modification. It tries to record *two* conflicts and fails at the second.

So what you can do is first merge the first bit (up to and including the
delete), resolve that conflict, and then run the rest of the merge. You need
to split the merge at any revision that is in the "did not exist" part.

If the conflicting modification is already committed on a branch, you can
also try to --ignore-ancestry, to make merge not notice that the file was
modified (I'm guessing, haven't tried it).

That's the workaround for 1.6, 1.6.1 and 1.6.2. As for the fix, it still has
some minor tail (see test added in r38099, r38100), and we're running late
with 1.6.3, so I kinda guess that it's not going to be in 1.6.3.

I can try to wrap it and nominate for backport, but I can't guarantee that
it'll get the remaining two votes in time to be included in 1.6.3.



To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].

Received on 2009-06-21 00:10:14 CEST

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