On 06/02/2010 04:04 PM, Stefan Sperling wrote:
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.
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 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.
Thanks you for the detailed explanation.
It is a little hard to wrap my head around the idea that although I
committed the change deleting foo/bar, I now have to update foo/ for my
working copy to truly reflect that foo/bar is deleted. To paraphrase
Johan from #3256, 'what "incoming edit"? Bumping the
revision number? The deleted file is already gone'.
I understand if this counter intuitive behavior is the natural
consequence of the way subversion is designed and is difficult to
change. However, perhaps there is a way to make this situation easier fo
users to understand or avoid? My first thought is that performing
deletes/moves/copies on an item that is not at HEAD could display a
warning message.
--
Brian Pitts
Systems Administrator | EuPathDB Bioinformatics Resource Center
706-542-1447 | b...@uga.edu | http://eupathdb.org
