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

replacing items (was: Re: ancestor path / revision)

From: Greg Stein <gstein_at_lyra.org>
Date: 2000-12-20 07:17:05 CET

On Tue, Dec 19, 2000 at 01:45:16PM -0600, Karl Fogel wrote:
> Greg Stein <gstein@lyra.org> writes:
> > We aren't supplying enough information in the editor callbacks.
> >
> > Consider the case of "svn copy" (replacing a file) and then a commit. This
> > will map into a replace_file() call. We need to tell the system three pieces
> > of information:
> >
> > 1) the revision of the file we're replacing (was it the latest?)
> > 2) the path of the file we copied
> > 3) the revision of the file we copied
>
> Remember, it's the directory entry that's really being replaced. In
> other words, in directory D at revision R, we're replacing the entity
> at entry F with a new entity, whose ancestry is APATH and AREV.

Strictly true, yes...

>...
> Perhaps the issue was that you thought you had to give the ancestry of
> the target entity as well as the ancestry of the source.

Yes.

> But you
> don't, of course -- the target ancestry is implied by the ancestry of
> the parent in which the target is being replace.

Well, I'm not quite so sure that I agree... the target's ancestry is *not*
implied by the parent. Consider the following operation:

$ svn update some/dir
[ a time period elapses ]
$ svn update some/dir/foo.c
P some/dir/foo.c # this updates foo.c to v7; dir is ???

Now, let's say that we attempt to copy something over the top of foo.c. If
we tell the server that we're replacing "foo.c, v6", then the server is
going to bark at us. It will complain because it doesn't know if you're
attempting to copy over v6 or v7 of foo.c.

[ of course, this is moot if we say the server shouldn't care about the
  overwrite, but I was under the impression that we *do* care. there could
  be "lost changes" if somebody deletes/replaces a file and didn't know that
  there were a dozen intervening changes. ]

And a separate topic/point: just what is the version of the directory in the
above case? I'd think it is somewhere between v6 and v7. Note that it isn't
v6 because foo.c is at v7. And it isn't v7 because we only fetched foo.c
(there may be other v7 changes in the directory that we *didn't* fetch).

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:17 2006

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