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 <[email protected]> CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
