Version Control with Subversion - Chapter 5. Repository Administration - Repository Data Stores
Repository Data Stores
As of Subversion 1.1, there are two options for storing
data in a Subversion repository. One type of repository
stores everything in a Berkeley DB database; the other kind
stores data in ordinary flat files, using a custom
format. Because Subversion developers often refer to a
repository as “the (versioned) filesystem”, they have
adopted the habit of referring to the latter type of repository as
filesystem implementation that uses the native OS filesystem
to store data.
When a repository is created, an administrator must decide
whether it will use Berkeley DB or FSFS. There are advantages
and disadvantages to each, which we'll describe in a bit.
Neither back-end is more “official” than another,
and programs which access the repository are insulated from
this implementation detail. Programs have no idea how a
repository is storing data; they only see revision and
transaction trees through the repository API.
Table 5.1, “Repository Data Store Comparison”
gives a comparative overview of Berkeley DB and FSFS
repositories. The next sections go into detail.
Table 5.1. Repository Data Store Comparison
|Sensitivity to interruptions
||very; crashes and permission problems can leave the
database “wedged”, requiring journaled
|Usable from a read-only mount
|Usable over network filesystems
|Scalability: number of revision trees
||database; no problems
||some older native filesystems don't scale well with
thousands of entries in a single directory.
|Scalability: directories with many files
|Speed: checking out latest code
|Speed: large commits
||slower, but work is spread throughout commit
||faster, but finalization delay may cause client
|Group permissions handling
||sensitive to user umask problems; best if accessed
by only one user.
||works around umask problems
||in use since 2001
||in use since 2004
[an error occurred while processing this directive]