On Wed, Jun 02, 2010 at 05:45:53PM -0400, Brian Pitts wrote:
> 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'.
Well... it's gone in *HEAD* :)
The item is still present in past revisions.
If you checked out the parent as of before you deleted the file,
you'd rightly expect the file to show up in your working copy.
A parent dir that is out-of-date has no way of knowing what happened to
its children in the future. At the time the tree conflict check is made,
we don't even know what changes the server wants to send for the directory.
All we know is that it wants to change something inside the directory.
And it does not matter what changes will be sent, because if the directory
isn't there (locally deleted), we cannot apply any changes anyway.
You happen to know that the incoming change is no-op, that it comes from
the very same working copy, and that no other commit happened in-between.
So the present state happens to semantically not conflict with the incoming
change. But Subversion doesn't know that. Any kinds of changes could have
happened between the directory's current revision and HEAD. For all we know
the child you deleted could have been re-added already, in which case
deleting the parent directory conflicts with the re-addition of the child.
Maybe svn could be a bit smarter about this, that would be nice.
But trying to be smarter can get really complicated very quickly.
> I understand if this counter intuitive behavior is the natural
> consequence of the way subversion is designed and is difficult to
> change.
Absolutely. But I'd argue that it's only counter-intuitive if you
haven't understood how Subversion works. At least the parts where
you have one new revision of the entire repository tree for every
commit, and where your working copy is usually a hodgepodge of many
of those revisions. The rest follows from there.
> 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.
I don't think such a warning would help much.
The moved item could be outdated a split-second after the move
completes, because a commit can happen any time.
A warning that triggers if an item is moved within a mixed-revision
working copy might help. Then again, people would probably see this
warning a lot, so it would be an annoyance (e.g. one extra click for every
delete/move/copy operation in TortoiseSVN). And it would make the situation
seem a lot more dramatic than it really is. After all, you already knew
how to resolve the conflict before you understood why it even happened.
Stefan
Received on 2010-06-03 00:35:47 CEST