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

RE: [PATCH] Issue 898 atomic rename, implement svn_fs_rename

From: <rassilon_at_lyra.org>
Date: 2003-01-23 18:10:11 CET

 From: Branko Cibej [mailto:brane@xbc.nu]
 cmpilato@collab.net wrote:
 For example, I was thinking that we could avoid a schema change for
 svn_fs_rename() by using information slots we (will) already have
 (after 1003 goes in):
    changes table: Add new rename change type.
    nodes table: The committed-path tells you what the new path is.
                   the source-noderev-id points to the previous
                   incarnation, and that node's
 committed-path tells you
                   what the source path was. We know that
 this isn't a
                   copy because nothing was added to the copies table.
 Er, that won't work. We can't go changing the node's
 committed-path after a rename, because the rename doesn't
 touch that node at all. The node's committed-path will always
 tell us what the /source/ of the /first/ rename was, but you
 can rename the file several times and not create a new node; e.g.,
     svn mv foo bar; svn ci; svn mv bar qux/baz; svn ci;
 Now, qux/baz points to a node-change whose committed-path is
 foo, and we don't even have a node-change with
 committed-path bar anywhere.

This gives us at least two interesting choices:
* Keep committed-path on node-revision.
* Add path back to changes table on the branch, but make it optional for
everything but renames.

This allows us not to bother recording committted path changes on
bubbled up directories, but it has the side-efffect of increasing the
cost of tree - dag mapping in open_path in tree.c. (specifically the
get_id_path routine).

* Go back to my initial approach and record bubble up directory changes
in the changes table.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 02:09:29 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.