Julian Foad wrote on Thu, Sep 08, 2011 at 10:56:43 +0100:
> On Thu, 2011-09-08 at 10:40 +0200, Stefan Sperling wrote:
> > On Thu, Sep 08, 2011 at 10:36:13AM +0200, Stefan Sperling wrote:
> > > So I would expect sharding within the successors tree
> > > to behave like this:
> > >
> > > filename: file stores successor data created in:
> > > db/successors/ids/0/0 r0..r999
> > > db/successors/ids/0/1 r1000..r1999
> > > ... ...
> > > db/successors/ids/0/999 r1000000..r1999999
> > > db/successors/ids/1/0 r2000000..r2000999
> > > ... ...
>
> Oops - something's wrong with that pattern. Did you mean .../ids/(rev %
> 1000000)/(rev % 1000) which would give
>
> db/successors/ids/0/0 r0..r999
> db/successors/ids/0/1 r1000..r1999
> ... ...
> db/successors/ids/0/999 r999000..r999999
> db/successors/ids/1/0 r1000000..r1000999
> ... ...
>
That's what the code is doing.
I'm testing it with FSFS_SUCCESSORS_MAX_REVS_PER_FILE=3 and
SVN_FS_FS_MAX_FILES_PER_DIR=4. I'd like to encourage people to use
different values for these constants than I use --- my experience shows
that some bugs only surface with some values of the constants.
> ?
>
> - Julian
>
>
> > (Of course, this example assumes max-files-per-dir == 1000,
> > which is the default.
> > With a different value the one-thousand-revisions-files
> > would distribute across directories in a different way.)
>
>
Received on 2011-09-08 12:33:19 CEST