On Tue, Sep 06, 2011 at 06:42:44PM +0300, Daniel Shahaf wrote:
> r1165700 mentions that we need to decide what to do with 'svnadmin
> upgrade'.
>
> 1. We could punt and require a dump/load. All format >=6 FSFS instances
> always have a full successors store.
>
> 2. We could store the progeny shard size and the successors data shard
> size in the 'format' file. If those values are absent (or zero),
> then the successor lookup operation returns SVN_ERR_UNSUPPORTED_FEATURE.
>
> We can also reconstruct the successors cache without a dump/load, via
> a tools/ binary that operates as follows:
>
> for (i = 0; i < CONSTANT; i++)
> check 'current' and build the successors data up to that revision
> with write lock:
> check 'current' and build the successors data up to that revision
> updates 'format' with the shard sizes
> (release write lock)
>
3. Have 'svnadmin upgrade' populate successor data by harvesting
existing revision files.
This will take a while. I don't know how long exactly.
As I mentioned in the commit message, if we do for this route we should
at least provide progress information (e.g. in form of outputting the
numbers of revisions which have been processed).
Upgrade code will also need to be written for the BDB backend.
Received on 2011-09-06 18:01:11 CEST