On 09/20/2011 09:38 AM, Daniel Shahaf wrote:
> To implement 'svnadmin upgrade' for fs-successor-ids, it seems we want
> code to do the following:
>
> def construct_successors_in_existing_fs(fs):
> def handle_range(range):
> for revision in range:
> for node-rev-id in fs->revisions[revision]:
> Add to 'successors' table: key=fs->nodes[node-rev-id].pred-id value=node-rev-id
>
> For range in 0..999, 1000..1999, ..., N*1000..youngest:
> in a txn, handle_range(range)
>
> in a txn, handle_range( (old youngest)+1..[txn's value of "youngest"] )
>
> Now, handle_range() needs to work with two tables at once --- reading
> from NODES and writing to SUCCESSORS --- and I haven't found any
> precedent in subversion/libsvn_fs_base/bdb/*.c for code that reads two
> tables at once. (locks-table.c reads from bfd->lock_tokens, but it
> doesn't read from bfd->locks in that function; and everything else only
> reads from the table the file is named after.)
>
> So, I'm asking what's the proper layout for this code: do I make
> a function in bdb/successors-table.c that reads from NODES and writes to
> SUCCESSORS? Or do I have a higher-level function (in, say, node-rev.c)
> that runs within a txn, reading NODES and calling SUCCESSORS?
I would probably go with a higher-level function that calls the appropriate
database-specific functions in the bdb/* layer.
But before we press on here, I'd like to understanding your bigger-picture
view. Why are you choosing to this by-revision in fs_base rather than using
a more lower-level, largely-Subversion-ignorant approach? Is it
specifically so you can have an interruptible/restartable process? Is it so
you can hook into some pre-existing per-revision subsystem (notification,
perhaps)?
(As to you follow-up mail, yes, the `miscellaneous' table is the best place
to store a progress pointer.)
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2011-09-21 16:31:19 CEST