[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 19:43:04 CET

 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

This is an archived mail posted to the Subversion Dev mailing list.