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:
1)
* 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).
2)
* Go back to my initial approach and record bubble up directory changes
in the changes table.
Thoughts?
Bill
---------------------------------------------------------------------
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