view release on metacpan or  search on metacpan

src/subversion/subversion/libsvn_fs_fs/structure  view on Meta::CPAN

Shard packing:
  Format 4:   Applied to revision data only.
  Format 5:   Revprops would be packed independently of revision data.
  Format 6+:  Applied equally to revision data and revprop data
    (i.e. same min packed revision)

# Incomplete list.  See SVN_FS_FS__MIN_*_FORMAT


Filesystem format options
-------------------------

Currently, the only recognised format option is "layout", which
specifies the paths that will be used to store the revision files and
revision property files.

The "layout" option is followed by the name of the filesystem layout
and any required parameters.  The default layout, if no "layout"
keyword is specified, is the 'linear' layout.

The known layouts, and the parameters they require, are as follows:

"linear"
  Revision files and rev-prop files are named after the revision they
  represent, and are placed directly in the revs/ and revprops/
  directories.  r1234 will be represented by the revision file
  revs/1234 and the rev-prop file revprops/1234.

"sharded <max-files-per-directory>"
  Revision files and rev-prop files are named after the revision they
  represent, and are placed in a subdirectory of the revs/ and
  revprops/ directories named according to the 'shard' they belong to.

  Shards are numbered from zero and contain between one and the
  maximum number of files per directory specified in the layout's
  parameters.

  For the "sharded 1000" layout, r1234 will be represented by the
  revision file revs/1/1234 and rev-prop file revprops/1/1234.  The
  revs/0/ directory will contain revisions 0-999, revs/1/ will contain
  1000-1999, and so on.

Packing revisions
-----------------

A filesystem can optionally be "packed" to conserve space on disk.  The
packing process concatenates all the revision files in each full shard to
create pack files.  A manifest file is also created for each shard which
records the indexes of the corresponding revision files in the pack file.
In addition, the original shard is removed, and reads are redirected to the
pack file.

The manifest file consists of a list of offsets, one for each revision in the
pack file.  The offsets are stored as ASCII decimal, and separated by a newline
character.

Packing revision properties (format 5: SQLite)
---------------------------

This was supported by 1.7-dev builds but never included in a blessed release.

See r1143829 of this file:
http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_fs_fs/structure?view=markup&pathrev=1143829


Packing revision properties (format 6+)
---------------------------

Similarly to the revision data, packing will concatenate multiple
revprops into a single file.  Since they are mutable data, we put an
upper limit to the size of these files:  We will concatenate the data
up to the limit and then use a new file for the following revisions.

The limit can be set and changed at will in the configuration file. 
It is 64kB by default.  Because a pack file must contain at least one
complete property list, files containing just one revision may exceed
that limit.

Furthermore, pack files can be compressed which saves about 75% of
disk space.  A configuration file flag enables the compression; it is
off by default and may be switched on and off at will.  The pack size
limit is always applied to the uncompressed data.  For this reason,
the default is 256kB while compression has been enabled.

Files are named after their start revision as "<rev>.<counter>" where
counter will be increased whenever we rewrite a pack file due to a
revprop change.  The manifest file contains the list of pack file
names, one line for each revision.

Many tools track repository global data in revision properties at 
revision 0.  To minimize I/O overhead for those applications,  we
will never pack that revision, i.e. its data is always being kept
in revprops/0/0.

Pack file format

  Top level: <packed container>

  We always apply data compression to the pack file - using the
  SVN_DELTA_COMPRESSION_LEVEL_NONE level if compression is disabled.
  (Note that compression at SVN_DELTA_COMPRESSION_LEVEL_NONE is not
  a no-op stream transformation although most of the data will remain
  human readable.)

  container := header '\n' (revprops)+
  header    := start_rev '\n' rev_count '\n' (size '\n')+

  All numbers in the header are given as ASCII decimals.  rev_count
  is the number of revisions packed into this container.  There must
  be exactly as many "size" and serialized "revprops".  The "size"
  values in the list are the length in bytes of the serialized
  revprops of the respective revision.

Writing to packed revprops

  The old pack file is being read and the new revprops serialized.
  If they fit into the same pack file, a temp file with the new
  content gets written and moved into place just like an non-packed
  revprop file would. No name change or manifest update required.