Branko Čibej <br...@wandisco.com> wrote: > On 21.11.2014 17:34, Branko Čibej wrote: >> As a counter-example, I'd much prefer to drop the ability to create >> non-sharded, non-packed FSFSv7 repositories; that would change the >> number of possible v7 layouts from 4 (or 8, with r1640915 in place) to >> just one, not counting shard sizes etc. > > To clarify, dropping non-sharded, non-packed layout options for FSFSv7 > was not an option as long as we had support for mixed-mode addressing as > well. Now that we agreed to remove that, restricting FSFSv7 to only > sharded+packed layout sounds like a good idea to me, from the point of > view of reducing the number of possible layouts.
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 activity and so there is no way to enforce that all or some or even any of the repository is packed. 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. Thoughts? - Julian
