Yep, completely agree with the end result (now that I'm not misreading
Jim's example).
I think we have "consensus", as they like to phrase it in co-op land. :-)
-K
Greg Stein <gstein@lyra.org> writes:
> On Tue, Sep 05, 2000 at 02:38:57PM -0500, Jim Blandy wrote:
> >
> > Suppose a user has a working directory containing a file, A, based on
> > version 10 (which I'll write `A:10').
> >
> > Assume that commits happen only when I explicitly say so; otherwise,
> > changes are just local to the working copy. Assume that all copies,
> > renames, etc. are done via the appropriate Subversion commands.
>
> "appropriate Subversion commands" is an important point here. It means that
> we are tracking what is occurring within the directory, and tracking the
> ancestry of the files.
>
> > The user copies A to B, yielding a new file B, based on A:10.
> >
> > The user updates the entire directory, and A is now based on version
> > 11; B is noted as an added, but not yet committed, file.
> >
> > The user deletes A.
> >
> > The user renames B to A. Now the working copy's A is based on A:10.
>
> The net effect here is that A is a NEW FILE whose ancestor is A:10. They
> happen to have the same name, but that does not alter the fact that it is
> a new file.
>
> An "update" will do nothing (except possibly remark on the added/uncommitted
> file named "A").
>
> A "commit" will check A:10 in as A:12. A change set (a version) in the
> server cannot record both a delete and an add for the same name (as far as I
> understand the "current" spec). Instead, it records an updated file with a
> specific predecessor. In this particular case, A:12 is created with A:10 as
> its predeccesor. A:11 has no successors, so it was presumably deleted.
>
> [ hmm. actually, we don't record predeccessors, do we? don't we just record
> "<this> file is in <this> version" ? only by comparing versions do we see
> the deltas between files? ]
>
> > Now, suppose the user does an update. No further changes have been
> > committed by anyone to the repository. Should A be brought up to
> > version 11? I think it shouldn't --- A's current text is something
> > the user explicitly chose. Their working copy is completely
> > up-to-date. I think Subversion should simply note that A is "locally
> > modified", and leave its contents alone. Do you agree?
>
> Agree.
>
> > Now, suppose the user does a commit. Should Subversion complain that
> > A is not up to date? Or should it simply check in the current
> > contents of the file --- effectively reverting the change made to A in
> > version 11? I think it should do the latter. This is the same
> > question as above, I think: "Is this file up-to-date?"
>
> Effectively, it will revert it. However, the predecessor/successor
> relationship is not "as you would expect". A revert would show A:11 as the
> predecessor and the net effect would be to reverse the A:10 -> A:11 change.
> In this scenario, the reality looks like:
>
> A:9 -> A:10 -> A:11 A:12
> \ /
> ----------
>
> Question is: can the SVN repository record this kind of relationship?
>
> > Now, when the user does a commit, what callbacks to the
> > svn_delta_walk_t structure need to happen? A single call to
> > replace_file doesn't work; the filesystem can't tell the difference
> > between that and attempting to commit an out-of-date version of A. I
> > think it needs to do a `delete', and then an `add_file'. I'm not so
> > sure about that. What do you think?
>
> You can do it either way:
>
> a) replace_file with an predecessor of A:10
> b) delete, followed by add_file with a predeccessor of A:10
>
> Both cases should resolve to the same thing.
>
> I'm okay with a declaration that only one form is "legal." I'd prefer option
> (a) if we make such a declaration. In other cases, we are going to want to
> have the ability to specify a set of predecessors (e.g. merges).
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:07 2006