On Wed, Oct 22, 2008 at 7:30 PM, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> David Glasser wrote:
>> On Wed, Oct 22, 2008 at 1:10 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>>> David Glasser wrote:
>>>> *nod*, reasonable. I'd still argue that (for FSFS) rep-sharing seems
>>>> to be a net loss, though.
>>> All the code to do rep-sharing should be wrapped up in FS-format-version
>>> conditionals -- should we expose rep-sharing as an option (in the format
>>> file) to the administrator and let him/her decide if the space savings is
>>> worth it?
>>
>> Might be a good idea. Note that (unlike sharding) I think that the
>> use of rep-sharing can be essentially turned on and off at will (as
>> long as reuse numbers are always parsed), so I'd advocate for putting
>> this in the new fsfs.conf rather than the format file. (Or y'all
>> could decide that I made a false dichotomy between format options and
>> configuration and ditch the fsfs.conf.)
>
> rep-sharing can be turned on and off pretty much at will. The cache can be
> blown away without any negative consequences, and the parser can be taught to
> ignore the reuse numbers.
>
> As far as fsfs.conf vs. the format file, what dichotomy did you choose? My
> feeling would be that values which should remain constant for the life of the
> repo (such as shard size) should go in the format file, while values which can
> be changed in a live repo should live in fsfs.conf. Does that feeling match
> reality?
That was basically what I thought, yeah: you can't just change the
sharding in a vacuum, but you can change memcache configuration.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-23 10:15:55 CEST