Version control

When writing my papers (and for many other things), I have been using some kind of version control software since about 1999. Among other things, what version control does is to allow you to preserve as many intermediate versions of your work as you want; any time I reach a point that I may want to preserve, a suitable command indicates that the current state of things must be remembered. Later on, it is also easy to recover those intermediate stages, and/or to compare one of them to the current state of the work (or indeed to compare two of the previous stages directly). In particular, it is useful to tag a paper as soon as it is submitted for publication. Then, even if I make changes or corrections while waiting for the refereeing process to slowly snail itself to send a report back, it remains very easy to look back (one, two, three or four years later) to check what was the exact text I had sent to the journal.

Version control is of course also particularly useful when collaborating because no amount of mistyping can lead to a situation where local changes by me erase a brilliant ten page development by a co-author (well, not really, since it is a theorem that for any computer there is a finite combination of letters which, typed properly, will erase everything on it…). It was particularly useful when I was translating into English a friend’s book on methods of mathematics for physicists. We both had the software configured so that any changes could be communicated to the other by asking the software for what had changed between our local copy and the reference version it controls. Since there were around a hundred source files for this book, including copies of the French original and of the (sometimes partially translated) English versions, plus figures, control files, etc, this was really convenient.

It is unfortunately not so trivial to set up version control, which is more commonly used by computer scientists for their projects (source code replacing LaTeX files). It should be fairly easy for a university to offer this as a service to its faculty (ETH, for instance, has something like this for software — anyone can register a software project at and this platform provides all that is needed, including version control, bug tracker, forums for interaction with users, access control for closed-source projects, wiki,…) but it doesn’t seem to be common for more academic work. (It could of course be a good project to adapt the system to this type of situation).

After moving to ETH, the setup I had been using in Bordeaux for about 8 years was not easily reproducible, and it took me a while here in Zürich to arrive at a smooth operation. (It’s still not quite as nice as before, but it’s getting there). I use the svn software for version control (with Linux), mostly for historical reasons (I know there are many other options). For local work on a single computer, the setup would be quite simple, but part of the point of this exercise is that I can keep multiple copies of my (past and present) work on different computers, and continue writing any paper on any of them, submitting the changes to a central server from which they can be recovered on all the others (this is useful also for backup, and during travels; if I make changes on some important files on my laptop during a conference or a visit to wonders of the earth, I can usually expect to be able to save it to the central server when I have internet access, and thus avoid losing too much if the laptop is destroyed or stolen — which has happened to me once…).

The main configuration issue is to have this server accessible from other computers in a semi-permanent manner. My setup in Bordeaux did not translate well to Zürich (partly for reasons of complexity and having forgotten part of the operating procedure…) However, the following works fine for the moment: I use a VPN connection to ETH to connect to the internet, which provides an IP address visible from the outside, even from behind a router/firewall. Then dyndns allows me to keep a permanent URL to access the server (which runs on an Apache web server with the required SVN module to permit access, and fortunately I just had to copy the old configuration file to make this work…)

Published by


I am a professor of mathematics at ETH Zürich since 2008.

5 thoughts on “Version control”

  1. Dear Emmanuel, i’m extremely happy to see that you decided to start a blog!
    I think that using a VCS for a “latex project” is a very good idea, in case that you wanted to give a look at an alternative i recommend you to consider git, it is a distributed VCS and a repository is even easer to set up than svn (there is no difference between the local checkout and the remote repository, every checkout can be used as ‘source’), you keep locally a copy of the whole history, and it is very good when you have to work offline (you can commit to the local repository, and later push the updates to the ‘server’ or to repositories that you may have on another computer), and it encourages you to create branches to store possible alternative developments (that may eventually be merged into the main project).
    If i will have some spare time, i’d really like to write a “git for Mathematicians Guide” some day.
    Best regards, and thanks for sharing your experiences!

  2. GIT (or distributed version control in general) does look like a good alternative. In fact, I started investigating it before I succeeded in getting SVN to work in Zürich. In the end, I decide to stay with it because it has worked well for me in terms of keeping my data safe, not because of the feature set itself (in fact, once there was a repository corruption due to hardware problems, and one of the SVN developers was kind enough to fix the database file himself, which is the kind of help one can often only dream of!). I have no reason to doubt that GIT will be as good, but one thing that seemed a bit shaky was the initial SVN-to-GIT import, to preserve history. There were two different scripts to do this, and the first one, though it claimed to have encountered no error, had only recovered a very partial view of the history. The second script (I don’t remember the names) apparently worked better, however.

  3. I similarly use cvs (for no better reason than what you give for using svn) for all my papers. The biggest problem arises when working with collaborators at other universities or even other departments at my own university: giving them access to my cvs repository is difficult, as the way I have it set up would require convincing my department’s computer support people to give them logins. In one case I’ve acquired a login at another university for exactly this reason; in others, I just exchange files by email and handle the version control part myself.

  4. I haven’t really tried to get co-authors to synchronize on version control, except for this book translation I mentioned. But then the access-right issue was simplified because the SVN server was on my home computer (accessible through dyndns), so I could set it up as desired. Indeed, I don’t think either Bordeaux then or ETH now would allow me to have an SVN server on the department computers.

    I’m vaguely thinking of contacting the Origo team here to see if building a similar tool for (research)-paper-oriented projects would be feasible…

Comments are closed.