RE: Cannot commit moved directory after adding (and committing) a child

> Van: Stefan Sperling [mailto:stsp_at_elego.de]
> > 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.

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.

>
> > - Error:
> > svn: Commit failed (details follow):
> > svn: Item '/trunk/test/test_moves/clean3/dir' is out of date
> >
[snip]
 
> 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.

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.
Regards,
Johan

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2389575

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-01 01:04:42 CEST