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:
> 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...
Received on 2009-09-23 17:04:51 CEST