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

Re: Issue #3486 (r38000 group) - Attempt to add tree conflict that already exists

From: Mark Phippard <markphip_at_gmail.com>
Date: Wed, 23 Sep 2009 11:06:15 -0400

On Wed, Sep 23, 2009 at 11:03 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Wed, Sep 23, 2009 at 10:53:18AM -0400, Mark Phippard wrote:
>> On Wed, Sep 23, 2009 at 6:39 AM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
>> > Hi tree-conflict fans.
>> >
>> > <http://subversion.tigris.org/issues/show_bug.cgi?id=3486>
>> >
>> > This is the bug that looks like:
>> >
>> >> $ svn merge -r10182:11149 https://svn/repo/trunk/foo .
>> >> svn: Attempt to add tree conflict that already exists at 'foo/src/x'
>> >> svn: Error reading spooled REPORT request response
>> >> $
>> >
>> > Possibly the main cause of extreme pain from this bug is that Subversion
>> > bails out of the merge when it hits this. If there are hundreds or
>> > thousands of items to merge, given that our merge is not easily
>> > re-startable from part way through, that makes it pretty much unusable.
>> >
>> > Paul Hammant brought this up the other day in a thread on <users@>,
>> > <http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396235>, and filed issue #3496 <http://subversion.tigris.org/issues/show_bug.cgi?id=3496> about it. From a later message I understand he is looking into modifying Subversion so that it moves on past this error rather than bailing out. That sounds like a sensible plan if it is possible to do so while maintaining a consistent state.
>> >
>> > The other approach is to try to fix all the cases that lead to this
>> > error, because there are not supposed to be any such cases. (Issue
>> > #3486.) However, although this approach is correct and Stefan and Neels
>> > in particular have been working successfully on it in the r38000 group
>> > of fixes (branch 1.6.x-r38000), it is taking a long time to find all the
>> > different cases and there is not yet a complete fix.
>> >
>> > Does anyone else think making svn cope with the problem and move on is
>> > sensible? If so, I think Paul could do with some help on it as he is new
>> > to Subversion coding (although very familiar with Subversion).
>> Thanks Julian, I relayed the same advice.
>> The patch has been posted to users@.  See:
>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2398899
>> Hopefully some of the tree conflicts gurus can look at it from an
>> approach standpoint and see if there is maybe a different way we can
>> handle these error situations.
> Oh, a patch?
> I will take look. Totally missed that thread...

Yes, but as Julian describes, this is not a patch for whatever the
problem is. It is a patch about how we treat errors in general. And
it is certainly not a finished patch but it is a working demonstration
of the concept.

Paul, BTW, if this patch "works" does it reveal anything more about
what the actual problem is so that work can happen towards fixing it?

Mark Phippard
Received on 2009-09-23 17:07:39 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.