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.
