[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: Ben Collins-Sussman <sussman_at_newton.collab.net>
Date: 2000-12-19 19:37:30 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

Let me spell out the two cases of "svn copy", as I understand things.

* Simple case:

    `svn copy foo.c bar.c', followed by a commit, would drive the
    editor like this:

    replace_dir()
       add_file (bar.c, ancestor="/absolute/path/to/foo.c", revision)
    close_dir()

* Complex case:

    `svn copy foo.c bar.c', where bar.c is *already* a file under
    revision control. (That's what you meant above, right?) :

    replace_dir()
       delete (bar.c)
       add_file (bar.c, ancestor="/abs/path/to/foo.c", revision)
    close_dir()

     The important issue here is to make sure the delete() happens
     before the add(). If we try to add before we delete, the
     filesystem should give us an error, telling us of a dirent
     namespace conflict.

     Also notice that I *didn't* need to supply the revision number of
     the "old" bar.c. That was already done in the earlier `report'.
     That's why the editor's "delete" command only mentions the name
     of the dirent; it's presumed that you're deleting a certain
     dirent under parent_path revision N.

     Similarly, I suppose this complex case could be handled by the
     single replace_file() call you mention. Again, the revision of
     the "previous" file is implied by the revision number of the
     parent dir.
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.