[RFC] Drop non-sharded layout option for FSFSv7? [was: ...r1640915...]
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Mon, 24 Nov 2014 10:20:09 +0000
Branko Čibej <brane_at_wandisco.com> wrote:
Firstly, as I understand it, sharded layout (with a given shard size) is a config option and applies to all or none of the revisions, whereas packing a shard is an asynchronous
Non-sharded layout is like a special case of sharded, with shard size = infinity and the intermediate directory level omitted. And it can't be packed, so we're talking about a much smaller impact than reducing "4 or 8" layouts to one.
Nevertheless I strongly support dropping any configuration options that aren't really useful, because reducing the number of configuration options does have a significant contribution to lowering the burdens of testing and support. I presume the non-sharded option has no significant real-world benefits over sharded with shard size = <more revisions than you'll ever have>.
Secondly, what are the upgrade options and issued when a user has a format 6 repo and upgrades to f7? Is it easy and cheap to upgrade non-sharded f6 to sharded f7, for example?
Thirdly, what do we mean by "supporting" or "dropping" an option? We don't currently have an option in "svnadmin create" to choose anything other than sharded with shard size = 1000. I believe the procedure to follow to get a different layout is to manually edit the "db/format" file after "svnadmin create" but before creating any revisions. But that's not a great system. If other layout options or shard sizes are "supported" we should allow them to be specified in "svnadmin create".
We could choose either to drop all the code for reading and writing the non-sharded layout (which probably amounts to only about ten lines of code), or just keep on omitting an option to create it but leave it supported if somebody manually creates it. The more important thing is not whether the code is there, but whether the option is included in our testing and our declared supported formats.
This is an archived mail posted to the Subversion Dev mailing list.