On Tue, Jun 07, 2011 at 07:08:44PM +0100, Jon Foster wrote:
> Hi,
>
> I'm having trouble resolving a tree conflict.
>
> I'm working on a feature branch, and I regularly merge from trunk to the
> branch. In my latest merge, I got a tree conflict because a directory
> ("playback") has been added both to trunk and to my branch, with
> different contents. I want to get rid of my version and use the one
> from trunk.
>
> This should be trivial, but it isn't:
>
> $ svn resolve --accept theirs-full playback
> svn: warning: Tree conflicts can only be resolved to 'working' state;
> 'playback' not resolved
Hi Jon, long time no see.
I hope your svnsync jobs are still running safely :)
As the error message explains, interactive conflict resolution isn't
implemented yet for tree conflicts. Sorry.
I hope this will be worked on for Subversion 1.8.
> So I thought I'd delete the directory and use "svn cp" to copy the
> branch version into my working copy. The delete worked:
>
> $ svn st --depth=empty playback
> D C playback
> > local add, incoming add upon merge
>
> And I can easily get the URL I need to copy from:
>
> $ svn info playback
> URL: http://svnserver/repos/branches/feature/wherever/playback
> ...
> Tree conflict: local add, incoming add upon merge
> Source left: (dir)
> http://svnserver/repos/trunk/wherever/playback@2373
> Source right: (dir)
> http://svnserver/repos/trunk/wherever/playback@3515
>
> But the copy doesn't work:
> $ svn cp http://svnserver/repos/trunk/wherever/playback@3515 .
> svn: Path 'playback' already exists
> (I also tried "svn cp
> http://svnserver/repos/trunk/wherever/playback@3515 playback", but that
> put it in the wrong place (playback/playback/ rather than just
> playback/) and seemed to get my working copy in a bugged state,
> requiring non-SVN "rm" and "svn cleanup" to get it working again).
>
> I guess I could split the commit into two - if I did a first commit for
> the rest of the merge and to delete the "playback" directory, I'd
> probably be able to use "svn cp" and do a second commit to re-add it
> with the right contents. This seems like a very ugly hack.
>
> Any ideas how to resolve this properly?
The problem is that the 1.6 working copy does not support
directory replacements properly. Think about what should happen
to the .svn directory in the locally deleted directory. It needs
to remain in place so you can revert your deletion if you decide
to do so. But it also interferes with adding a new directory before
you commit the deletion, because the new directory would need
a different .svn directory at the same place!
So you really need two commits.
However, your approach should perfectly work fine with a 1.7 client
because meta-data has been centralised in a single .svn directory
in the root directory of the working copy. So if you got time please
try the 1.7.0-alpha1 release which should hopefully be released during
the next couple of days and report back. Thanks!
BTW, replacing directories does work more or less by accident in some
situations in 1.6, e.g. if a merge brings in both the delete and add
parts of a directory replacement -- but that is a small miracle and
your situation is one where it does not work at all.
Received on 2011-06-07 21:49:01 CEST