Ping - final call for feedback :).
If I hear no objections within a couple of days, I'll file this as an issue.
In the meantime, I've noticed that http://subversion.tigris.org/issues/show_bug.cgi?id=1539 is similar to this issue. But it's not quite the same if I understand correctly.
Johan
> Van: Johan Corveleyn [mailto:johan.corveleyn_at_uz.kuleuven.ac.be]
>
> 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&dsMes
> sageId=2392719
>
> To unsubscribe from this discussion, e-mail: [users-
> unsubscribe_at_subversion.tigris.org].
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393578
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-11 12:02:12 CEST