[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?

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2398935
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.