FSFS and fs-successor-ids

[Daniel Shahaf <d....@daniel.shahaf.name>]

The fs-successor-ids branch adds successor ids (effectively, copyto
information) to the BDB backend.  It hasn't touched libsvn_fs_fs or
libsvn_fs yet.

Has design of this feature for FSFS been discussed at all?  I couldn't
find anything in the archives.


I suggested yesterday on users@ to create a new hierarchy (parallel to
revs/ and revprops/) and to store information regarding the successors
of /path/to/foo@rN023 somewhere under $new_hierarchy/N/N023/** --- where
'somewhere' is to be defined.  (I have some unfinished thoughts about this.)


Also, I haven't seen the successor-ids during upgrade considered.  Do we
consider the successor ids ('successors' table, or $new_hierarchy/) just
a cache of derived information (like node-origins), or does it have to
be retroactively-populated at the time of and by 'svnadmin upgrade'?

Re: FSFS and fs-successor-ids

["C. Michael Pilato" <cm...@collab.net>]

On 11/29/2010 05:58 AM, Daniel Shahaf wrote:
> The fs-successor-ids branch adds successor ids (effectively, copyto
> information) to the BDB backend.  It hasn't touched libsvn_fs_fs or
> libsvn_fs yet.
> 
> Has design of this feature for FSFS been discussed at all?  I couldn't
> find anything in the archives.

No.  I had always assumed that we'd just dump the information into SQLite.

> Also, I haven't seen the successor-ids during upgrade considered.  Do we
> consider the successor ids ('successors' table, or $new_hierarchy/) just
> a cache of derived information (like node-origins), or does it have to
> be retroactively-populated at the time of and by 'svnadmin upgrade'?

It really needs to be populated in full, because real-time calculation is
unfeasible from a performance standpoint.  This means that once in place,
this code will either be an 'svnadmin upgrade' blocker ("svn:error:Cannot
upgrade to version N -- you must perform a full dump and load of your
repository.") or a feature blocker ("svn:error:Repository lacks successor
information required to answer your query -- consider dumping and re-loading.").

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand