subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Foad <julianf...@btopenworld.com>
Subject [RFC] Drop non-sharded layout option for FSFSv7? [was: ...r1640915...]
Date Mon, 24 Nov 2014 10:20:09 GMT
Branko ─îibej <brane@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

Mime
View raw message