The designers of
Subversion have created an open-source version control tool that fixes the flaws and addresses shortcomings in the popular Concurrent Versions System (CVS) version control system. The following are the most significant and visible CVS flaws that Subversion rectifies:
- CVS lacks directory versioning. It keeps track of only files, not directories.
- CVS has weak support for the copy, rename, and delete operations on files, a result of the lack of directory versioning.
- CVS lacks atomic commits.
In addition to these highly visible shortcomings, CVS also has the following less obvious shortcomings:
- CVS lacks versioned metadata. It can remember file permissions, but that is about it.
- CVS is hard to extend. There is no API that makes extension an easy process.
Subversion provides the following features that either fix the CVS flaws or improve upon existing CVS features:
- Subversion tracks both files and directories. So when you delete directories, they stay deleted in checkouts—no more specifying the "-dP" option to prune empty directories.
- Subversion handles the copy, rename, and delete operations on files well.
- Subversion performs its commit operations in an atomic fashion. So you will never have an inconsistent code tree as a result of the version control tool. Subversion ensures that either the entire commit or none of it happens. You will never get the situation in which the commit breaks in the middle, leaving some files checked in and others not. Subversion rolls back the whole commit operation, similar to how a relational database operates.
- Subversion provides a well-documented API that allows other applications to embed or extend it.
- Subversion has a uniform method of dealing with all files, both binary and text. It has a binary differencing algorithm that works on text files. You no longer need to tag files as binary or text.
- Subversion has more ways of accessing the repository. While CVS has direct filesystem, pserver, and ssh/rsh remote access, Subversion has direct filesystem, svnserve (analogous to pserver), ssh, and WebDAV. The Subversion API is extensible and makes it easy to add more types of access (for instance, integration with your favorite IDE).
- The powerful API means that Subversion can be extended in ways that CVS cannot (for instance, with new access methods or with new storage backends).
This article first describes how easy it is to start with Subversion by creating a new repository. CVS users should find it especially easy. Next, it shows how to connect to a Subversion repository and how to operate on the newly created repository with commands to modify its contents (operating on files and directories within the repository). It then describes how you will typically use Subversion commands in day-to-day development, showing some of the frequently used commands. Finally, it addresses two advanced Subversion topics: wedging, an infrequent and harmless problem, and branching/tagging, ways of organizing versions of file sets.
CVS to Subversion: An Easy Switch
In order to make the tool easy to use, the Subversion designers adopted many of CVS's commands and usage patterns. This means that not only do you get to use the same commands, but you also use them in the same way for the most part. Switching to Subversion from CVS is therefore very easy. It is also easy to pick up Subversion from scratch.
To demonstrate how Subversion works, the following instructions show you how to start using it on a sample project. You need to have Subversion already installed on your computer. (To download Subversion, go to subversion.tigris.org and find the latest version.)
The first thing you must do is set up a repository. The repository, a simple directory with some subdirectories and files, holds all of the files pertaining to your project. You can have multiple repositories on a single machine or filesystem, and you can store the repository anywhere on your filesystem (although it should be a local filesystem, not an NFS or otherwise remote filesystem—an upcoming section discusses how to set up a repository on local filesystems or other machines).
For the most part, you will deal with two commands when using Subversion: svnadmin and svn. You will use the svn command almost all of the time. The commands check out, commit, update, difference, and other operations are all present in the svn main command. You will use svnadmin to create and maintain your repositories.
To create the repository on your local filesystem, issue the following command (do not actually issue this command right now):
svnadmin create /path/to/repository
You do not have to be root to create a repository. However, if you want other people to be able to check out items and/or commit items to your repository, they must have permission to do so. The best way to do this on a Unix system is to put the users in a group and then make the directories and files in the repository readable by that group. You should make the directories and files in the repository writable by the group if you also want to allow group members to commit to your repository.
To create the repository, first make sure that you have a directory called "/srv/svn". If you do not have this directory on your filesystem, create it. Make sure it is writable by the user who will be creating the Subversion repository. If you do not have root access, you can use another directory, but make sure to substitute that directory whenever the instructions specify /srv/svn. Issue the following command:
svnadmin create /srv/svn/first-project-repository
If you view the contents of the /srv/svn directory, you will see a first-project-repository subdirectory. If you look inside the first-project-repository directory, you will see a directory listing like the following:
drwxrwxr-x 2 wchao wchao 4096 Dec 27 15:25 conf
drwxrwxr-x 2 wchao wchao 4096 Dec 27 15:25 dav
drwxrwxr-x 2 wchao wchao 4096 Dec 27 15:25 db
-r—r—r— 1 wchao wchao 2 Dec 27 15:25 format
drwxrwxr-x 2 wchao wchao 4096 Dec 27 15:25 hooks
drwxrwxr-x 2 wchao wchao 4096 Dec 27 15:25 locks
-rw-rw-r— 1 wchao wchao 376 Dec 27 15:25 README.txt
The contents of the first-project-repository, as you can see, are just regular files and directories. You should not, however, touch these files. The svn command operates on the files in the repository, so you should not need to touch them directly unless the repository gets wedged (more on that in the "Wedging, Branching, and Tagging" section at the end).
More...