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

Re: 'svnadmin upgrade' Re: FSFS successor ID design draft

From: Stefan Sperling <stsp_at_elego.de>
Date: Tue, 6 Sep 2011 18:00:23 +0200

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

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.