Malcolm Rowe <malcolm-svn-dev@farside.org.uk> writes:
>> Why would this be this non-backward-compatible? I can see why it's
>> not forward-compatible, but backward-compatibility should be possible
>> here.
>
> Perhaps I meant forward-compatible - I always get those muddled. What I
> meant is that an older client can't access a sharded repository. New
> clients can access older repositories, of course.
Ah, yes. It will be backward-compatible, but not forward-compatible.
>> Are you sure max-files-per-dir has to be configurable? If we're going
>> to have the code in there anyway, would it be possible to just pick
>> some reasonable values and then make this the new default for FSFS?
>> (With the old format still supported, of course.) Are you sure it
>> would be so much less efficient than the current storage mechanism
>> that we need to retain the option of not sharding?
>>
>
> Well, I guess my woolly line of thinking goes like this:
>
> - Most people probably don't need this feature. You'd need quite a lot
> of revisions to make it worthwhile.
> - I do need some way to create repositories that older clients can access.
> If sharding is on by default, I could either use a
> --pre-1.5-compatible switch (or --fsfs-not-sharded), or, if it's off
> by default, something like --fsfs-sharded.
> - I don't have the information to choose the most efficient size of
> directory. I could choose a reasonable value (4096? 10000?) and
> that'd be okay...
Can we get that information?
> - ... but if I need per-filesystem options for the local-txn-storage
> idea anyway...
> - ... then I could punt on making a decision and make the user specify
> the number of files is they want sharded storage...
I understand, but when we punt on making that decision, we're forcing
the user to make it.
> - ... and if they don't know they want it, they don't get it, so our
> repositories are compatible with 1.4 by default.
Why do we need compatibility with 1.4 clients for file:// by default?
(We're only talking about file:// here, as I understand it.)
Oh, because clients might be running on other servers and accessing
the repository via NFS. Hmmm. But we've had incompatible upgrades
before: in the working copy format, at least, and perhaps also in the
repository format (I can't recall exactly, just think we've done it).
> I guess the things holding me back from making it the default are:
> - it's inelegant if you have a decent filesystem.
> - we still need to support both methods, it's just a metter of where
> the switch is located.
> - I can't really set a policy for the right number of files myself.
> - I quite like the idea of making it opt-in rather than opt-out, and
> of reusing the options mechanism to do so.
But the result would be that the repositories we create by default are
not as scalable as they could be. Absent the compatibility concerns,
is there any reason why we wouldn't make the new way the default?
Maybe the answer is a two-stage upgrade. First add the ability to
create and recognize those repositories, but turned off by default.
Next minor version, make it the default...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 5 16:31:22 2007