WB 2.08.x

### This file controls the configuration of the FSFS filesystem.

[memcached-servers]

### These options name memcached servers used to cache internal FSFS

### data.  See http://www.danga.com/memcached/ for more information on

### memcached.  To use memcached with FSFS, run one or more memcached

### servers, and specify each of them as an option like so:

# first-server = 127.0.0.1:11211

# remote-memcached = mymemcached.corp.example.com:11212

### The option name is ignored; the value is of the form HOST:PORT.

### memcached servers can be shared between multiple repositories;

### however, if you do this, you *must* ensure that repositories have

### distinct UUIDs and paths, or else cached data from one repository

### might be used by another accidentally.  Note also that memcached has

### no authentication for reads or writes, so you must ensure that your

### memcached servers are only accessible by trusted users.

[caches]

### When a cache-related error occurs, normally Subversion ignores it

### and continues, logging an error if the server is appropriately

### configured (and ignoring it with file:// access).  To make

### Subversion never ignore cache errors, uncomment this line.

# fail-stop = true

[rep-sharing]

### To conserve space, the filesystem can optionally avoid storing

### duplicate representations.  This comes at a slight cost in

### performance, as maintaining a database of shared representations can

### increase commit times.  The space savings are dependent upon the size

### of the repository, the number of objects it contains and the amount of

### duplication between them, usually a function of the branching and

### merging process.

###

### The following parameter enables rep-sharing in the repository.  It can

### be switched on and off at will, but for best space-saving results

### should be enabled consistently over the life of the repository.

### 'svnadmin verify' will check the rep-cache regardless of this setting.

### rep-sharing is enabled by default.

# enable-rep-sharing = true

[deltification]

### To conserve space, the filesystem stores data as differences against

### existing representations.  This comes at a slight cost in performance,

### as calculating differences can increase commit times.  Reading data

### will also create higher CPU load and the data will be fragmented.

### Since deltification tends to save significant amounts of disk space,

### the overall I/O load can actually be lower.

###

### The options in this section allow for tuning the deltification

### strategy.  Their effects on data size and server performance may vary

### from one repository to another.  Versions prior to 1.8 will ignore

### this section.

###

### The following parameter enables deltification for directories. It can

### be switched on and off at will, but for best space-saving results

### should be enabled consistently over the life of the repository.

### Repositories containing large directories will benefit greatly.

### In rarely read repositories, the I/O overhead may be significant as

### cache hit rates will most likely be low

### directory deltification is disabled by default.

# enable-dir-deltification = false

###

### The following parameter enables deltification for properties on files

### and directories.  Overall, this is a minor tuning option but can save

### some disk space if you merge frequently or frequently change node

### properties.  You should not activate this if rep-sharing has been

### disabled because this may result in a net increase in repository size.

### property deltification is disabled by default.

# enable-props-deltification = false

###

### During commit, the server may need to walk the whole change history of

### of a given node to find a suitable deltification base.  This linear

### process can impact commit times, svnadmin load and similar operations.

### This setting limits the depth of the deltification history.  If the

### threshold has been reached, the node will be stored as fulltext and a

### new deltification history begins.

### Note, this is unrelated to svn log.

### Very large values rarely provide significant additional savings but

### can impact performance greatly - in particular if directory

### deltification has been activated.  Very small values may be useful in

### repositories that are dominated by large, changing binaries.

### Should be a power of two minus 1.  A value of 0 will effectively

### disable deltification.

### For 1.8, the default value is 1023; earlier versions have no limit.

# max-deltification-walk = 1023

###

### The skip-delta scheme used by FSFS tends to repeatably store redundant

### delta information where a simple delta against the latest version is

### often smaller.  By default, 1.8+ will therefore use skip deltas only

### after the linear chain of deltas has grown beyond the threshold

### specified by this setting.

### Values up to 64 can result in some reduction in repository size for

### the cost of quickly increasing I/O and CPU costs. Similarly, smaller

### numbers can reduce those costs at the cost of more disk space.  For

### rarely read repositories or those containing larger binaries, this may

### present a better trade-off.

### Should be a power of two.  A value of 1 or smaller will cause the

### exclusive use of skip-deltas (as in pre-1.8).

### For 1.8, the default value is 16; earlier versions use 1.

# max-linear-deltification = 16

[packed-revprops]

### This parameter controls the size (in kBytes) of packed revprop files.

### Revprops of consecutive revisions will be concatenated into a single

### file up to but not exceeding the threshold given here.  However, each

### pack file may be much smaller and revprops of a single revision may be

### much larger than the limit set here.  The threshold will be applied

### before optional compression takes place.

### Large values will reduce disk space usage at the expense of increased

### latency and CPU usage reading and changing individual revprops.  They

### become an advantage when revprop caching has been enabled because a

### lot of data can be read in one go.  Values smaller than 4 kByte will

### not improve latency any further and quickly render revprop packing

### ineffective.

### revprop-pack-size is 64 kBytes by default for non-compressed revprop

### pack files and 256 kBytes when compression has been enabled.

# revprop-pack-size = 64

###

### To save disk space, packed revprop files may be compressed.  Standard

### revprops tend to allow for very effective compression.  Reading and

### even more so writing, become significantly more CPU intensive.  With

### revprop caching enabled, the overhead can be offset by reduced I/O

### unless you often modify revprops after packing.

### Compressing packed revprops is disabled by default.

# compress-packed-revprops = false