This file describes the design, layouts, and file formats of a libsvn_fs_fs repository. Design ------ In FSFS, each committed revision is represented as an immutable file containing the new node-revisions, contents, and changed-path information for the revision, plus a second, changeable file containing the revision properties. In contrast to the BDB back end, the contents of recent revision of files are stored as deltas against earlier revisions, instead of the other way around. This is less efficient for common-case checkouts, but brings greater simplicity and robustness, as well as the flexibility to make commits work without write access to existing revisions. Skip-deltas and delta combination mitigate the checkout cost. In-progress transactions are represented with a prototype rev file containing only the new text representations of files (appended to as changed file contents come in), along with a separate file for each node-revision, directory representation, or property representation which has been changed or added in the transaction. During the final stage of the commit, these separate files are marshalled onto the end of the prototype rev file to form the immutable revision file. Layout of the FS directory -------------------------- The layout of the FS directory (the "db" subdirectory of the repository) is: revs/ Subdirectory containing revs / Shard directory, if sharding is in use (see below) File containing rev .pack/ Pack directory, if the repo has been packed (see below) pack Pack file, if the repository has been packed (see below) manifest Pack manifest file, if a pack file exists (see below) revprops/ Subdirectory containing rev-props / Shard directory, if sharding is in use (see below) File containing rev-props for .pack/ Pack directory, if the repo has been packed (see below) . Pack file, if the repository has been packed (see below) manifest Pack manifest file, if a pack file exists (see below) revprops.db SQLite database of the packed revprops (format 5 only) transactions/ Subdirectory containing transactions .txn/ Directory containing transaction txn-protorevs/ Subdirectory containing transaction proto-revision files .rev Proto-revision file for transaction .rev-lock Write lock for proto-rev file txn-current File containing the next transaction key locks/ Subdirectory containing locks / Subdirectory named for first 3 letters of an MD5 digest File containing locks/children for path with node-origins/ Lazy cache of origin noderevs for nodes File containing noderev ID of origins of nodes current File specifying current revision and next node/copy id fs-type File identifying this filesystem as an FSFS filesystem write-lock Empty file, locked to serialise writers pack-lock Empty file, locked to serialise 'svnadmin pack' (f. 7+) txn-current-lock Empty file, locked to serialise 'txn-current' uuid File containing the repository IDs format File containing the format number of this filesystem fsfs.conf Configuration file min-unpacked-rev File containing the oldest revision not in a pack file min-unpacked-revprop Same for revision properties (format 5 only) rep-cache.db SQLite database mapping rep checksums to locations Files in the revprops directory are in the hash dump format used by svn_hash_write. The format of the "current" file is: * Format 3 and above: a single line of the form "\n" giving the youngest revision for the repository. * Format 2 and below: a single line of the form " \n" giving the youngest revision, the next unique node-ID, and the next unique copy-ID for the repository. The "write-lock" file is an empty file which is locked before the final stage of a commit and unlocked after the new "current" file has been moved into place to indicate that a new revision is present. It is also locked during a revprop propchange while the revprop file is read in, mutated, and written out again. Furthermore, it will be used to serialize the repository structure changes during 'svnadmin pack' (see also next section). Note that readers are never blocked by any operation - writers must ensure that the filesystem is always in a consistent state. The "pack-lock" file is an empty file which is locked before an 'svnadmin pack' operation commences. Thus, only one process may attempt to modify the repository structure at a time while other processes may still read and write (commit) to the repository during most of the pack procedure. It is only available with format 7 and newer repositories. Older formats use the global write-lock instead which disables commits completely for the duration of the pack process. The "txn-current" file is a file with a single line of text that contains only a base-36 number. The current value will be used in the next transaction name, along with the revision number the transaction is based on. This sequence number ensures that transaction names are not reused, even if the transaction is aborted and a new transaction based on the same revision is begun. The only operation that FSFS performs on this file is "get and increment"; the "txn-current-lock" file is locked during this operation. "fsfs.conf" is a configuration file in the standard Subversion/Python config format. It is automatically generated when you create a new repository; read the generated file for details on what it controls. When representation sharing is enabled, the filesystem tracks representation checksum and location mappings using a SQLite database in "rep-cache.db". The database has a single table, which stores the sha1 hash text as the primary key, mapped to the representation revision, offset, size and expanded size. This file is only consulted during writes and never during reads. Consequently, it is not required, and may be removed at an arbitrary time, with the subsequent loss of rep-sharing capabilities for revisions written thereafter. Filesystem formats ------------------ The "format" file defines what features are permitted within the filesystem, and indicates changes that are not backward-compatible. It serves the same purpose as the repository file of the same name. The filesystem format file was introduced in Subversion 1.2, and so will not be present if the repository was created with an older version of Subversion. An absent format file should be interpreted as indicating a format 1 filesystem. The format file is a single line of the form "\n", followed by any number of lines specifying 'format options' - additional information about the filesystem's format. Each format option line is of the form "