On Fri, Aug 28, 2009 at 05:14:34PM +0200, Johan Corveleyn wrote:
> I think I've seen this being discussed before (on the list or in the issue tracker), but can't find it again. So if anyone remembers, or can shed any light on this, I would very much appreciate it.
>
> Following up on "tree changes that cause problems for wc-1 (and that I would like to verify if wc-ng will fix)", as in http://svn.haxx.se/users/archive-2009-08/0630.shtml, I saw some other strange behavior. I'm not sure whether this is a bug or "as designed":
>
> Short description (recipe below):
> - Do some "tree action" (e.g. adding a file) in a directory. Commit it.
> - Then move the directory. Commit.
Remember that in Subversion, a move equals copy+delete, which equals
add-with-history+delete. I don't think that's particularly great,
but it's the way it is.
> - Error:
> svn: Commit failed (details follow):
> svn: Item '/trunk/test/test_moves/clean3/dir' is out of date
>
> Going further:
> - svn up: Tree conflict:
> D C dir
> > local delete, incoming edit upon update
> - svn resolve. Changes are now committed correctly.
>
> I guess the basic explanation is that this is caused by the mixed revision thing (i.e. the directory is a revision number behind, after committing the new file). So it thinks it is out of date, although it obviously isn't (also, "svn st -u" reports nothing, so it too thinks the directory is really up to date). I would consider this a bug.
>
This is by design. When you commit, only the files/directories that
are actually changed by the commit ("commit targets") get their base
revisions bumped in the working copy. The other files/directories
(possibly including the directory you committed from) don't get
their base revisions bumped.
See also http://subversion.tigris.org/faq.html#hidden-log
'svn status -u' is right saying that there are no incoming changes.
What matters here is the base revision of the directory, as shown
by 'svn info'. If it isn't at HEAD, svn update will try to update
the directory to HEAD. Any local changes you have can then conflict
with this update.
I know this can be confusing, in particular because of tree conflicts
you can inflict upon yourself. But svn has no way of knowing that you
yourself just comitted the file addition which caused the directory
to be out-of-date during the second commit. And allowing an out-of-date
directory to be committed may cause certain tree conflicts not to be
detected, so svn can't allow you to do this.
E.g. committer_1 commits the result of "svn move a b", and committer_2
does "move a to c" and tries to commit this in the next revision.
This is clearly a tree conflict and needs to be detected. Committer_2's
commit needs to fail, to require an update which then shows the tree
conflict.
Note that, currently, this conflict is really flagged as "svn rm a"
vs. "svn rm a", which is a false positive in case both comitters really
deleted 'a' instead of moving it -- but there is no way to tell the
difference with the current design :(
So to avoid your problem, you should update after committing the addition,
and then do the move. Moving things around in mixed-revision working copies
may work in some cases, but is a bad idea in general because of issues like
this.
WC-NG will really know what a "move" is, and the situation will gradually
improve over time as the concept of "move" propagates through the system,
from working copy to client->server interface to filesystem to server->client
interface to working copy. There's a lot left to do before we get there.
But the current behaviour is certainly intentional right now, and not a bug.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2388346
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-28 20:12:10 CEST