Subversion repository creation is an incredibly simple
task. The svnadmin utility that comes with
Subversion provides a subcommand (
for doing just that.
$ svnadmin create /var/svn/repos
This creates a new repository in the directory
/var/svn/repos, and with the default
filesystem data store. Prior to Subversion 1.2, the default
was to use Berkeley DB; the default is now FSFS. You can
explicitly choose the filesystem type using the
--fs-type argument, which accepts as a
$ # Create an FSFS-backed repository $ svnadmin create --fs-type fsfs /var/svn/repos $
# Create a Berkeley-DB-backed repository $ svnadmin create --fs-type bdb /var/svn/repos $
After running this simple command, you have a Subversion repository.
The path argument to svnadmin is just
a regular filesystem path and not a URL like the
svn client program uses when referring to
repositories. Both svnadmin and
svnlook are considered server-side
utilities—they are used on the machine where the
repository resides to examine or modify aspects of the
repository, and are in fact unable to perform tasks across a
network. A common mistake made by Subversion newcomers is
trying to pass URLs (even “local”
file:// ones) to these two programs.
Present in the
db/ subdirectory of
your repository is the implementation of the versioned
filesystem. Your new repository's versioned filesystem begins
life at revision 0, which is defined to consist of nothing but
the top-level root (
Initially, revision 0 also has a single revision property,
svn:date, set to the time at which the
repository was created.
Now that you have a repository, it's time to customize it.
While some parts of a Subversion repository—such as the configuration files and hook scripts—are meant to be examined and modified manually, you shouldn't (and shouldn't need to) tamper with the other parts of the repository “by hand”. The svnadmin tool should be sufficient for any changes necessary to your repository, or you can look to third-party tools (such as Berkeley DB's tool suite) for tweaking relevant subsections of the repository. Do not attempt manual manipulation of your version control history by poking and prodding around in your repository's data store files!