Jim Blandy <jimb@savonarola.red-bean.com> writes:
> 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?
I think it should update. It should try to merge in the version 11
changes to A, as it would have if none of the renaming back and forth
had ever taken place, right? If it can't merge, then there's a
conflict, to be resolved according to the usual means.
Before the update, the local A is just a modified file based on
version 10 of A. This was not changed by the renaming to and from B.
So the update should behave accordingly.
> 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?"
I think it should commit, and whether or not this reverts the v11
change depends on how the merge/conflict thing went.
> 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?
I think the problems in this paragraph are resolved by the answers in
the previous ones, but let me know if I'm missing something.
-K
Received on Sat Oct 21 14:36:07 2006