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.) > >
