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 | bdp@uga.edu | http://eupathdb.org
Received on 2010-06-02 23:46:30 CEST