On Wed, Jun 02, 2010 at 01:04:38PM -0400, Brian Pitts wrote:
> Hi,
>
> I'm experiencing a tree conflict in a situation where there should be no
> conflict. Basically, after removing the contents of a directory I'm
> unable to commit deleting the directory even though no one has modified
> it. The client is 1.6.6. I've tried with server versions 1.4.3 and
> 1.6.9. Below is a simple demonstration
>
> $ mkdir foo
> $ svn add foo/
> A foo
> $ svn commit -m "Add dir foo"
> Adding foo
>
> Committed revision 1738.
> $ echo 'Hello World' > foo/bar
> $ svn add foo/bar
> A foo/bar
> $ svn commit -m "Add file bar in dir foo"
> Adding foo/bar
> Transmitting file data .
> Committed revision 1739.
> $ svn rm foo/bar
> D foo/bar
> $ svn commit -m "Remove file bar from dir foo"
> Deleting foo/bar
>
> Committed revision 1740.
Look at the output of
svn info foo
at this point. You'll see that foo is not at the HEAD revision,
i.e. something older than 1740.
foo/bar was bumped to the HEAD revision because it was a commit target.
But foo was not a commit target so it is left at whichever revision
it was before you started the commit. This is called a "mixed-revision"
working copy. See
http://svnbook.red-bean.com/nightly/en/svn.basic.in-action.html#svn.basic.in-action.mixedrevs
So foo is now out of date. You need to update now, *before* removing
the directory. But you didn't do so.
> $ svn rm foo/
> D foo
Because you did not update, you have just deleted a directory which
is based on an outdated revision (i.e. not HEAD).
In general, deleting or moving or copying things in a mixed-revision
working copy is a bad idea. Try to avoid doing so. Copy, move, and
delete can operate on URLs directly, without needing a working copy.
Using URLs avoids problems arising from mixed-revision working copies.
> $ svn commit -m "Remove directory foo"
> Deleting foo
> svn: Commit failed (details follow):
> svn: Item '/puppet/foo' is out of date
> $ svn update
> C foo
> At revision 1740.
> Summary of conflicts:
> Tree conflicts: 1
svn status now says the tree conflict is "local delete, incoming
edit upon update"
The incoming edit in this case is the delete of the child foo/bar.
Subversion cannot tell whether the incoming change was committed from
your own working copy or not. Nor should it care. It simply wants to
update the directory foo from an older revision to HEAD. To do this it
needs to change something inside of foo (delete foo/bar).
But you have locally deleted foo, so Subversion cannot apply the
incoming change! So there's a conflict.
> At this point, I have to use 'svn resolve --accept working foo/' to
> accept the deletion. Afterwards, I can successfully commit it. Can
> anyone explain this behavior?
This is called a "self-inflicted" tree conflict.
This has been discussed a few times, for example here:
http://old.nabble.com/Cannot-commit-moved-directory-after-adding-%28and-committing%29-a-child-td25191764.html
http://svn.haxx.se/dev/archive-2010-03/0496.shtml
Hope this helped,
Stefan
Received on 2010-06-02 22:04:41 CEST