On Tue, Sep 05, 2000 at 06:06:53PM -0500, Jim Blandy wrote:
>...
> > > 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?
Whenever you delete or replace a file, the protocol should specify *which*
version you're attempting to delete or replace.
Thus, "replace A:<empty> with A:10" vs "replace A:10 with <change>" can be
distinguished. Lessee... I'm not up on my XML delta spec, but something
like:
<replace-file name="A">
<add-file name="/A" ver="10" />
</replace-file>
<replace-file name="A" ver="10">
...
</replace-file>
In the second version, the client is saying "I'm replacing A, version 10
with something". The server goes "no you're not. update first."
The first version says "I'm replacing <nothing> [because it was deleted]
with something. in this case, /A version 10."
Again: delete should also specify the version of what is being deleted. In
this case, though, I think we just issue a warning "you deleted an out of
date version, but I'll delete the head." Alternatively, the server could
demand an update and the client will merge [<new-version>, <deleted-local>]
into simply <deleted-local> (with the appropriate tweak of the local's
version number). The commit will then let the deletion of the latest go
through.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:08 2006