Ping
Is there anyone who agrees or disagrees with the ideas explained below? Or is this totally naive or just plain stupid :) ?
Summary: after a tree change directly below a directory (e.g. file added/removed), I think SVN should bring the revision number of that directory up to date with the committed revision (like it does with a file after committing a modification to that file).
Rationale: I think a tree change below a directory is very similar to a content change of a file. I.e. the "contents" of the directory are modified. I think it should be handled as such. This would avoid the "self-inflicted tree conflict" described below (which is ultimately caused by the wc not being fully aware of the change it just committed).
Consequence: If the repository contains already another tree change in that directory (e.g. another file added), you will not be able to commit the addition of a file into it, until you update (merge) the directory. This is again exactly analogous to committing a file modification for a file that has been changed in the meantime (-> out-of-date error).
Any feedback appreciated, even if it's only to point out any obvious flaws I'm overlooking ...
Regards,
Johan
> Van: Johan Corveleyn [mailto:johan.corveleyn_at_uz.kuleuven.ac.be]
> > 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&dsMes
> sageId=2389575
>
> To unsubscribe from this discussion, e-mail: [users-
> unsubscribe_at_subversion.tigris.org].
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2392719
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-09 03:24:08 CEST