Okay --- I'm glad we all agree on the semantics the user should see.
> > 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?
Yep.
> > 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.
Assuming a), how would you tell the difference between our scenario
and an attempt to commit a change to an out-of-date version of the
file? They both look like a call to replace_file with an ancestor
older than the current, don't they?
Received on Sat Oct 21 14:36:07 2006