On Fri, Nov 9, 2012 at 2:07 PM, Stefan Sperling <s...@elego.de> wrote:
> On Mon, Apr 09, 2012 at 09:46:34PM -0000, stef...@apache.org wrote: > > Author: stefan2 > > Date: Mon Apr 9 21:46:34 2012 > > New Revision: 1311476 > > > > URL: http://svn.apache.org/viewvc?rev=1311476&view=rev > > Log: > > Turn hard-coded deltification parameters into config parameters > > for format 4 and later (they all keep compatibility with 1.6 and 1.7). > > I just came accross this snippet in the config: > > > +"### The following parameter enables deltification for properties on > files" NL > > +"### and directories. Overall, this is a minor tuning option but can > save" NL > > +"### some disk space if frequently merge or if you frequently change > node" NL > > +"### properties. You should not activate this if rep-sharing has been" > NL > > +"### disabled." > NL > > +"### property deltification is disabled by default." > NL > > +"# " CONFIG_OPTION_ENABLE_PROPS_DELTIFICATION " = true" > NL > > I don't like the sound of "You should not active this if..." > Changed the wording in r1407959. > This sounds as if we're relying on users to keep their configuration > files consistent to get proper behaviour, which I hope isn't the case! > > What happens if this option is activated anyway? Will the user be > left with a corrupt repository, or will the option have no effect, > or something else? > It will still use DELTA representations instead of PLAIN for properties. There is no functional hazard here, this is about efficiency only. The point is that DELTA reps come with a ~10 byte overhead for the initial rep in the delta chain. With rep sharing enabled, only a few reps will contain file properties (all shared between many files), so there will be little total size overhead. OTOH, properties on folders are often larger (compression will kick in above 512 bytes) and change from time to time - mostly due to mergeinfo. Here, deltification will save high percentages of the plain property rep size. But as the comment says, the total savings are usually small which means that even small, yet frequent, overheads may result in a net increase of repository size. -- Stefan^2. -- Certified & Supported Apache Subversion Downloads: * http://www.wandisco.com/subversion/download *
