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

Re: back-end fsfs DB corruption? - attempt to merge uncovering it

From: Stefan Sperling <stsp_at_elego.de>
Date: Mon, 14 Sep 2009 19:17:08 +0100

On Fri, Sep 11, 2009 at 01:29:07PM -0500, Paul Hammant wrote:
> (svn 1.6.3 server and client)
> When we do a merge, we get 3/4 of the way through and encounter a tree
> conflict, that effectively halts it. Many hours work down the drain
> as there's no --resume feature.
> When trying to reproduce it, but more quickly, we're having some
> success exposing it with a "--accept theirs-full" merge (w/o
> specifying a diff3-cmd argument).
> It ends like so:
> --- Merging r1234 through r2345 into 'foo/Foo'
> G foo/Foo
> --- Merging r1234 through r2345 into 'foo/Bar'
> G foo/Bar
> svn: Attempt to add tree conflict that already exists
> svn: Error reading spooled REPORT request response
> Is the source file in error 'foo/Bar' or some unnamed file that
> follows it ?

There are 3 bugs you have run into, all of which are known
and fixed:

1) Tree conflicts can only be resolved to 'working' state right now,
   and svn should not be fooling users into thinking 'theirs-full'
   etc. applies to tree conflicts.
2) The "attempt to add tree conflict that already exists" error
   does not print the path of the double-tree conflict victim.

3) It is possible to corrupt the working copy during a tree conflict
   which involves a replace. This is what is stopping your merge.
The first problem has been fixed in 1.6.5, the other two will be
fixed in 1.6.6. The fix for 3) was scheduled for 1.6.5 but had to
be postponed because it needed more work, unfortunately. But it
is done now.

If you want to get the fixes for 2) and 3) early, these commands
will produce patches you can apply to a 1.6.5 source tree:

svn diff -c39111 http://svn.collab.net/repos/svn/branches/1.6.x > 2.patch

svn diff http://svn.collab.net/repos/svn/branches/1.6.x@39163 \
  http://svn.collab.net/repos/svn/branches/1.6.x > 3.patch

Then go to the directory were you unpacked the subversion source
code and run:
  patch -p0 < 2.patch
  patch -p0 < 3.patch
and compile Subversion as usual. Should patch complain about not being
able to patch the file STATUS, just ignore this.

You can also work around 3) by splitting up your merge range so that
the replace does not happen in a single merge/commit cycle.
However, this workaround isn't possible if a file was replaced within
a single revision (which can also happen for directories under certain
circumstances, but which is actually not supported by design in 1.6.x).
In this case, you will really need the patch for 3) to carry out the merge.

Apologies for the inconvenience,


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-14 20:17:57 CEST

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

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