From: cmpilato@collab.net [mailto:cmpilato@collab.net]
Bill Tutt rassilon@lyra.org writes:
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?
From a storage perspective, we're talking 6.1 and a half
dozen here. A change is only slightly more data than a
committed-path (byte-wise, at least). Also, we really can't
afford much more a hit on the open-path cost -- that function
is used for every FS function. I'm torn, because I was
starting to like the idea of the nodes knowing their
committed-paths, but I think approach 2 might be the better one.
Are there other costs involved that you know of, Bill?
Well, to be fair the increase in cost of open for change #1 is still
slightly less than the cost for change #2 because we only have to
examine the changes table if the current path != committed path to do
rename detection. However, the #2 approach always has to examine the
changes table.
I think I'm leaning towards #1.
Additionally, we should seriously consider whether or not so many FS
APIs should really take complete repository paths as arguments instead
of a directory baton that could contain at minimum a svn_fs_root, and
the directory entry hash and a entry name.
I don't know of any other costs for supporting renames (via #1) in the
filesystem layer. We do need to decide whether or not the
svn_fs_revisions_changed() API needs to be adapted to deal with this new
wrinkle however. The WC layer is going to have its own set of issues of
course, but we've talked about those before.
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:41 2006