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"] )
Received on 2011-09-20 23:02:42 CEST