Ben asked me to chime in.
On Mon, 2007-03-05 at 07:08 +0000, Malcolm Rowe wrote:
> The first is the ability to split your revs/ and revprops/ directories
> into separate 'buckets' or 'shards', so that we don't require a
> repository with a million revs to contain a million files in one
I think this is a relatively easy and quick hack, and I've commented in
the past that I'd like to see it done at least to measure its
performance impact. So I'd say go for it. I used to have an opinion on
the exact format of the splitting, but I've long since forgotten what it
Some of the subsequent discussion centered around whether we should make
it the default (thus making 1.5 repositories unreadable by 1.4 backend
code, and possibly breaking some hackish third-party tools which make
assumptions about the current FSFS layout). I'd suggest not making it
the default in 1.5 unless it has a marked performance benefit on a
repository of, say, 10,000 revs on a common filesystem. When 1.6 rolls
around, making it the default would be less of an issue.
Note that changing from a sharded layout to a non-sharded layout does
not necessarily require a dump and reload. We could create a tools/
script to reorganize an existing repository as an offline (but quick)
> For those people who are using a NAS to store the repository, FSFS
> really really really sucks.
I've had decent experience using it in AFS, which I'm guessing has a
lower penalty for opening and closing files than NFS does (or at least,
the implementation of NFS you're testing with).
Your proposed change seems okay, but I'm not sure how successful it
might be in a multi-vendor environment. The repository tells me to
marshal transactions in /tmp, which works great on my Unix systems, but
my Windows systems don't have a C:\tmp directory so it fails. Perhaps
the option should just be a boolean "marshal transactions in temporary
storage", so that Subversion can figure out the most appropriate
temporary directory, worry about not stomping on other users on the same
machine, etc.. Just an idea.
> So, here's the plan:
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Mar 5 19:56:51 2007