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.
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.
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?
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?"
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?
Received on Sat Oct 21 14:36:07 2006