Short Introduction

The command-line client is svn. You can get help with svn help or svn help <subcommand>, for example: svn help checkout.

Checking out a Project (locally)

Go into the directory where you want the checked-out copy of your project to be placed. This example:

svn co file:///vol/ims/svn/trunk/imslib

checks out the project imslib (svn co can be used as abbreviation of svn checkout).

Since svn can also check out projects from remote repositories the location of the repository is specified with a URL, file:///vol/ims/svn/trunk/imslib in this example.

The URL consists of two parts: file:///vol/ims/svn specifies that the subversion repository is located at /vol/ims/svn/ in the current filesystem. trunk/imslib specifies that what is wanted is actually in the subdirectory trunk/imslib within the subversion repository. Subversion stores its repository in its own format (for example in Berkeley DB files) so while you can look at the directory /vol/ims/svn using regular unix command-line tools (such as ls), there is no directory /vol/ims/svn/trunk or /vol/ims/svn/trunk/imslib. It's a bit like a filesystem within a filesystem, only that the subversion file system is under version control.

If you want to see how the repository looks like, you can use svn list (or svn ls in its abbreviated form):

$ svn ls file:///vol/ims/svn/
$ svn ls file:///vol/ims/svn/trunk/

Rüssel und Zweige

The trunk/, branches/ and tags/ directory are part of the recommended repository layout. The current development is supposed to happen in the trunk/ subdirectory.

The way subversion handles branches and tags is different to what CVS does: In Subversion, when you decide that the version of your project should be tagged or branched, you just copy the entire project directory over to the branches/ or tags/ directory. Copies are O(1) in subversion so that should be fast even for large projects. When you want to work on a branch you just check out the corresponding directory:

svn co file:///vol/ims/svn/svn/branches/calib/everything-new-and-shiny/

and work on that.

Regular Work

Commiting Changes

svn commit myfile.cpp

Updating the Working Copy

svn update

Seeing What You Have Changed


svn status

to see in what files your changes are. Do not run svn update just to see what you have changed.


svn diff

(optionally with a file name) to see differences between your working copy and the version your have originally checked out.

You can also abbreviate most commands. Just run svn help to see the commands and their abbreviations.

Checking out from a Remote Repository

svn checkout svn+ssh://

and add the following line to your ~/.bashrc (in the CeBiTec!):

if ! /vol/local/bin/which svnserve >& /dev/null; then export PATH=$PATH:/vol/subversion-1.6/bin/; fi


echo "PATH=/vol/kerberos/bin:/vol/local/bin:/vol/gnu/bin:/vol/X11/bin:/usr/dt/bin:/usr/openwin/bin:/usr/bin:/usr/ccs/bin:/usr/local/bin:/vol/openssh/bin:/vol/subversion-1.6/bin" > ~/.ssh/environment

This is required because the non-login ssh session would otherwise not find the svnserve binary.

Sometimes you (or someone else) may have made and commited changes which you want to undo. The easiest way (I know) to do this is the svn cat command, which does the same as cvs up -p. Imagine to have a file called testfile and you want to go back to revision 100:

svn cat -r 100 testfile > testfile
svn ci -m 'reverted to revision 100' testfile

Resolving conflicts

Subversion differs from cvs in the way it handles conflicts. Whenever a conflict occurs, the respective file is marked as conflicting and has to be unmarked by the user. This protects us from non-intentionally overwriting the conflicting file, e.g. with our last version without the changes of other people. So before commiting you have to call svn an extra time:

svn resolved testfile
svn ci testfile

Subversion book chapter 3 section 5.4

Sending E-Mail After a Commit

Change /vol/ims/svn/hooks/post-commit if you want to get commit mails for a project. Read the comments in that file.

Automatic Keyword Replacement

Put one of these strings in your document: $Date$ $Revision$ $Author$ $Id$

You have to enable automatic keyword replacement on the file before it works. This example enables the Date and Revision keywords on document.tex:

svn propset svn:keywords "Revision Date" document.tex

Remember that changes to properties don't take effect immediately, they have to be committed just like regular changes.

The $Id$ field looks like this: $Id: test2 2819 2006-01-17 10:21:33Z mmartin $

Other Things

Migrating a repository (or folder in that) to another repository

if a repository has to be migrated to another location then the svnadmin dump | load commands can be used. For example type the following to get a dump file containing all repository contents

svnadmin dump /path/to/repository > dumpfile

If only one project/subfolder should be migrated try the following:

svnadmin dump /path/to/repository | svndumpfilter include --drop-empty-revs --renumber-revs subfolder > dumpfile

Please note, that svndumpfilter will fail, if you have restructured your project by moving, adding or deleting directories.

After that the dumpfile can be imported into a new repository with:

svnadmin load /path/to/new_repository/ < dumpfile

Make sure that there is a repository at that location (svnadmin create /path/to/new_repository/)

After migrating you can switch your exiting repository copies with the following If you are currently inside such a directory type:

svn switch url:// .

For further information go to the following page:


Problems to be solved: WWW, giwww, SMP (WWW: IMS web pages, giwww: GI web pages, SMP: Doris' stuff, need to tell her how check out the code)

Reasons for the Switch

Why CVS is Inferior

CVS is not sufficient when we want to

  • rename files or directories
  • or move files or directories.

Keeping the history (the log messages) requires one to rename the file in the repository itself. This leads to problems when later one wants to check out an older version of the file: The old version, but with the new name, is retrieved.

CVS does not track changes to directories. Directory renames and moves aren't even possible without modifying the repository manually – leading to the same problem as with files when older versions are checked out.

There are other problems, but those mentioned above are issues we have encountered while working with CVS. Every time we develop an algorithm outside of imslib and later import it into the library we need to copy files. Currently we do it by copying the file manually and checking it in, but this loses all history, no one will know later on where the file came from, unless that is documented manually.

Why Subversion is Better

Subversion solves the problems mentioned above. File or directory moves are under version control and are as easy as svn move oldname newname.

Subversion was designed to be similar to CVS. Most simple CVS commands work in a similar way by just replacing the name of the executable cvs with svn.

The problem we had: “Automatically check out a specific submodule common to more than one project when a project is checked out.” can be solved with so-called properties, see svn:externals in the Subversion Handbook.

For more reasons why Subversion is cool, see