Re: odd cases

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/