RE: Cannot commit moved directory after adding (and committing) a child
From: Johan Corveleyn <johan.corveleyn_at_uz.kuleuven.ac.be>
Date: Tue, 1 Sep 2009 01:03:40 +0200
> Van: Stefan Sperling [mailto:stsp_at_elego.de]
Yeah I know :). But that's not really the problem I think. I suppose the same problem would occur if I just wanted to delete the directory.
Thanks for the explanation, Stefan. It made me understand better and think harder (which is always a good thing :)). I understand that this is currently the normal behavior (and I do believe you that it will gradually improve with wc-ng, hopefully closely followed by real move support and (better) tree conflict resolution).
However, all that aside, I still think there is something fishy about the way this is handled. Theoretically speaking, it's really a contradictory situation: I make a change, I commit that change, and yet my WC is not fully up to date with the change I made (or at least, it doesn't realize it is up to date).
If I would consider a tree change directly under directory "mydir" as a modification of its contents (just like editing a file is modifying that file's contents), it seems logical to me that mydir is brought fully up to date with the committed rev after committing the addition of a file under it (just like committing a modification to a file brings its revision number up to date in the wc).
This means that if, on committing the file addition, it's discovered that the directory's lastChangeRev is higher that the rev that had in my wc, I should then get an "out-of-date" error, just like with committing files (someone else had modified the file / dir in the meantime). On updating the dir, I could be lucky if there is no conflict (e.g. someone else committed another file in the dir, not conflicting with mine), so the "modified contents of the directory" can be automatically merged. If I'm not so lucky, I might have a tree conflict (which might in the future also be automatically resolved). But at least, I can't be in conflict with my own change...
Does that make sense?
I'm not saying SVN is totally wrong here, but I think the above behavior would be better. Of course, I could just as well be totally off base here, since I don't know SVN's internals nor the details and trade-offs of its design.
Thanks for your time.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
This is an archived mail posted to the Subversion Users mailing list.