This branch exists to reimplement the revprop-packing in FSFS f6 without
SQLite.  Several strategies have been discussed on the mailing list here:
http://svn.haxx.se/dev/archive-2011-07/0134.shtml

The concrete design proposal has been patched into the 'structure' file; you
may review it via

   svn diff ^/subversion/trunk/subversion/libsvn_fs_fs/structure \
            ^/subversion/branches/revprop-packing/subversion/libsvn_fs_fs/structure

See issue #3944: http://subversion.tigris.org/issues/show_bug.cgi?id=3944


TODO:

* add code catering for virus scanners during atomic move-into-place

* implement per-shard locking
  + add sequence number; adjust readers accordingly

* sync 'structure' with the implementation
  + manifest record alignment
  + manifest record width (bytes)

* check for offset overflow (in manifest)

* add some explicit tests for svnadmin upgrade/pack
  (both revs and revrops)

* implement 'hotcopy' support
  (currently tests fail --- r1296975)

* cf fs-successor-ids plans:
    Date: Fri, 26 Aug 2011 13:14:32 +0200
    From: Stefan Sperling <stsp@elego.de>
    To: dev@subversion.apache.org
    Subject: FSFS successor ID design draft
    Message-ID: <20110826111432.GA8819@ted.stsp.name>


Suggested:

* each revprops blob should include its rev number, length, and checksum,
  prepended to the blob itself.  (Or if it's awkward to prepend
  a checksum, put those things at the end, and omit the length as it is
  redundant by then.)

* store edits in non-packed files

* edit the revpack file in-place
  (requires aligning the manifest records to powers of 2)

* multiple offsets per manifest record

* append edits directly to the pack file, never have non-packed revprops

* manifest offsets as s/ASCII/unserialized integers/


Wishlist or out-of-scope:

* keep old revprop values for auditing

* script to downgrade f5 to f4

* finer-grained (two-staged) locks for other operations
  (eg, packing revision shards)

* cache some/all revprops in a pack file when reading it
  (see r1296604 thread)


Not a problem:

* ensure concurrent writers are not starved
  (Not more of a problem than it is with large commits today. Shouldn't
  be a problem in practice. Perhaps the antivirus retry logic will help,
  too.)