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,
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2394728
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-14 20:17:57 CEST