Daniel Shahaf wrote on Tue, Sep 20, 2011 at 16:38:33 +0300: > 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 >
Another issue here (which applies to FSFS too): how to store the 'partial progress'? I'm thinking we could maintain a record of max-successors-revision, initialized to 0 by 'svnadmin upgrade', updated by the "Construct successors in existing FS" procedure each time it finished handling a revision, and finally deleted once the (atomically) youngest revision was handled. (In particular, this assumes that we will not require the successors store to be constructed as a precondition to bumping the FS format number.) The public API's implementation can then, as long as the record exist, directly return an error. (We could optionally implement a mode where the API returns the results already stored and in addition says "I am only returning the successors not younger than rX".) The record can be implemented as a 'miscellaneous' table entry for BDB and either as a line in the 'format' file or as a new file in the root of the FS (sibling to min-unpacked-rev, format, et al) for FSFS. > 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"] )
