[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: implementing 'upgrade' for fs-successor-ids

From: Daniel Shahaf <danielsh_at_elego.de>
Date: Wed, 21 Sep 2011 00:01:52 +0300

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.