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

Re: ancestor path / revision

From: Karl Fogel <kfogel_at_galois.collab.net>
Date: 2000-12-19 20:45:16 CET

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.

All of those facts can be expressed with the editor interface, as far
as I'm aware (?).

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. But you
don't, of course -- the target ancestry is implied by the ancestry of
the parent in which the target is being replace.

This is also why replace_root() doesn't take any ancestry arguments:
when the root is truly / in the repository, it simply can't be
replaced, any more than you can do "mv / /blah" in Unix. Even when
it's not / in the repository, you still couldn't replace it without
affecting its parent, and the whole point of replace_root() is to
limit the scope of the change -- replace_root() names the topmost
point affected by a given change.

I should add, though, that if the editor interface needs rejiggering,
that's totally fine. I don't think anyone is wedded to it. But it's
worked out very well so far, and the examples you gave also seem to
work within it.
Received on Sat Oct 21 14:36:17 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.