Jim Blandy <jimb@savonarola.red-bean.com> writes:
> 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. The working copy's `A' is *not* the same as the one coming
from the server -- the resemblance of filename is not enough. Like
you said, the user explicitly chose the contents of working copy `A'.
> 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?"
Also agree. If the user commits, it's a deliberate action. We don't
want Subversion to second-guess a user's intentions; the user deleted
a file and added a file. When the user commits, that's *exactly* what
the commit should do. The fact that everything is called "A" is
irrelevant; that's why we have ancestry information.
> 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?
Exactly. The tree-delta would be something like
<tree-delta>
<delete name="A"/>
<add name="A">
<file ancestor="/A" ver="10"/>
</add>
</tree-delta>
I'm asssuming that this tree-delta is moving our repository tree from
version 11 to version 12. The first `delete' command would remove
A:11 altogether from tree 12. The second `add' command would create a
new file whose ancestor is A:10. Thus, in the repository, A:12 would
probably just be a back-link to A:10.
Received on Sat Oct 21 14:36:07 2006