SVN Page

Catherine suggested that we put all the bits and pieces we learn about SVN in one place. A jolly good idea as I do tend to forget about things!

---

As a CVS user, migrating to SVN was not without it's hiccoughs. Let's begin with some technical details:

Setting up your SVN details

(1) If you've got an account on the SVN server at WWMM, you should have a certificate file need by SVN to authenticate a session. Let's call this file svn_cert.p12. Place it in a convenient place, say, $HOME/certificates/

(2) Now edit the file $HOME/.subversion/servers It should contain the lines:

[groups]
wwmm = wwmm.ch.cam.ac.uk
                                                                                
[wwmm]
ssl-client-cert-file = $HOME/certificates/svn_cert.p12
ssl-client-cert-password = <the password Catherine gave you>

I'm not sure if you have to put your password there, but if you do, SVN won't prompt you for a password each time you try to use it.

(3) I found it convenient to define an environment variable pointing to my SVN directory on the WWMM server:

SVN=https://wwmm.ch.cam.ac.uk/svn/users/am592
export SVN

You could just add those lines to your .bashrc file.

Now you are set.

--alston 14:22, 31 October 2006 (GMT)

Creating a Project

There seem to be a couple of ways of doing this. The method reccommended by the SVN book (Version Control with Subversion - O'Reilly) is to use svnadmin create. This won't work as none of us users have access to the svnadmin command. The following works quite well:

$ svn mkdir $SVN/project1

This will create directory project1 in the repository. The svn mkdir command can also be used to make a directory in your working copy, but more on this later.

Now your project has its own directory on the SVN server. Let's get the files into it.

$ ls my_code
a.f90  b.f90
$ svn import my_code $SVN/project1
Adding     my_code/a.f90
Adding     my_code/b.f90
Committed revision 1.

That's done. Notice that the project is called my_code in my directory but project1 on the server. The names could be the same. --alston 14:22, 31 October 2006 (GMT)

Checking out a project

To check out a project from the repository:

$ svn checkout $SVN/project1 [PATH]

where $SVN/project1 is the URL for the project in the repository. If PATH is not given, subversion will create the same directory structure for you (if PATH is given, it will create any directories which don't exist).

svn co is shorthand for the svn checkout.

--jss43 13:50, 31 October 2006 (GMT)

Help

svn help <command> is very useful, as is the O'Reilly book, which available free online (and for download) here: SVN book.

--jss43 12:34, 31 October 2006 (GMT)

Differences

It's exceptionally useful to check the difference between a local file and the repository version. svn does provide svn diff, but this uses the standard diff engine, which is somewhat unhelpful. You (apparently) can change your diff engine (e.g. to xxdiff) in your ~/.subversion/config file, but I have never got this to work. Instead, I wrote a function using svn cat in my ~/.bashrc which does the job:

svndiff () {
    if [ "$#" -eq 0 -o "$1" == "-help" -o "$1" == "--help" ];    then
        echo "Usage: svndiff <file> [-r revision_number]"
        echo "Compare local copy to specified revision in the subversion"
        echo "repository (default: last commit) using xxdiff."
    else
        tempfile='\tmp\`basename $1`
        svn cat $@ > $tempfile
        xxdiff $1 $tempfile
    fi
}

The servers do not have xxdiff installed, but they do have vimdiff, which works similarly as above. You can pass flags through such as revision number, so long as they come *after* the filename.

--jss43 12:34, 31 October 2006 (GMT)

The workstations definitely have xxdiff and it could be installed on the servers too - mail me if you want it installing --Catherine 12:34, 1 November 2006 (GMT)

Logs

Logs can quickly become very length, so I find piping svn log through less is a good option (particularly as I tend to be more interested in recent changes). Note that unless you specify a revision number, you will only see the logs of commits from before your last update (so if you commit code, you won't see your own log message until you update your local version). The verbose flag results in the changed paths being printed out as well (very handy!).

Status

svn status returns the status of all the files in the current directory (or the path specified). This is a pain if you have lots of files produced by compiling your code/tex files, Makefiles and the ilk, which are not (and should not be) under source code management. svn status returns these marked by ?, which is not good if you have a few hundred such files. Fortunately, there is a way to change this! Open up ~/.subversion/config in your favourite text editor (which ought to be vi). Lines starting with # are comment lines. Uncomment [miscellany] and global-ignores. In the global ignores line, add any filenames and extensions you wish to ignore (e.g. *.o).

svn info gives you some useful information on a file/path (or current directory if no path is specified).

--jss43 12:44, 31 October 2006 (GMT)

Reverting

So, you have made some changes to your code and committed them, and now realise that your changes break everything. One of the strengths of using subversion (and other source code management systems) is to allow you to rollback code, however this is not intuitive in subversion.

svn revert <filename> reverts your *local* version back to the repository version. It doesn't accept a -r flag, so you can't use it to go back to older versions in the repository. It is useful if you've made some temporary changes for testing purposes, as you can revert to your clean code with one command).

(As an aside svn revert -R . will revert all files in the current and lower directories.)

To rollback to a previous version, first you need to find out which revision number you want to revert to. Then use svn update in a cunning way:

svn update -r <revision number>

--jss43 13:45, 31 October 2006 (GMT)