On Fri, Nov 9, 2012 at 2:07 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Mon, Apr 09, 2012 at 09:46:34PM -0000, stefan2_at_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
*
Received on 2012-11-11 13:39:12 CET