[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: odd cases

From: Greg Stein <gstein_at_lyra.org>
Date: 2000-09-09 02:09:54 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.