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
That's the tool I had in mind, but to "lazily populate the cache" is
the tricky bit.
Mark Phippard wrote on Tue, Sep 06, 2011 at 11:50:40 -0400:
> If it makes any sense, you could look at what we did in 1.5 for merge
> tracking.
>
> Merge tracking required a new bit of information -- the node or
If it makes any sense, you could look at what we did in 1.5 for merge tracking.
Merge tracking required a new bit of information -- the node origin
index. Dump/Load automatically populated this index. svnadmin
upgrade bumped the format but did not populate the index. Instead the
index was lazil
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 th
4 matches
Mail list logo
