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
