Creating the Repository
Subversion repository creation is an incredibly simple task. The svnadmin utility that comes with Subversion provides a subcommand (svnadmin create) for doing just that.
$ # Create a repository $ 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 Berkeley
DB; the default is now FSFS. You can explicitly choose the filesystem
type using the --fs-type argument, which accepts as a parameter either fsfs or bdb:
$ # 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.
Tip
The path argument to svnadmin
is just a regular filesystem path and not a URL such as 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 they 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 (/) directory. 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.
Warning
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!