Subversion
02 December 2006
I recently decided to put all my files under a real version control system. I've always had an ad hoc version control system anyway, grouping my files into experiments and keeping a journal of notes and results for each experiment, but there was no easy way to track the history of files and view recent changes. Also, I felt it was important to check-in the exact set of code and experimental data that produced published results and to be able to return to that state at any point. And finally, I run the same code on multiple computers (laptop and cluster) and version control is an easy way to sync files. So I spent an afternoon a few weeks ago setting up svn on a remote server and uploading projects. It wasn't completely painless though, and I've jotted down a few of the issues that came up in the process.
First of all, you need a repository. A year ago, I paid for web hosting from dreamhost and they have a 1-click svn installer. Unfortunately, it wasn’t as simple as it should have been, but some of the problem was my fault. On my web site, I run the content management system Joomla (also 1-click install from dreamhost) and I had enabled search engine friendly (SEF) links. This feature essentially rewrites URLs to make them human readable and also easier to archive by search engines.
The magic happens in the .htaccess file with a few rewrite rules. I had to add a few rules to prevent the server from rewriting svn (and stats) URLs. Here’s what I added to my .htaccess file to get it working. I actually don’t remember what these lines mean exactly (since I wrote them a few weeks ago…), but at the time they seemed correct and they fixed the problem.
RewriteCond %{REQUEST_URI} ^/stats/(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^/svn/(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^/failed_auth.html$
RewriteRule ^.*$ - [L]
After this fix, I could get to my repository and everything seemed to be working fine. Mac OS X comes with command line svn in the developer tools so I didn’t need to install anything extra there.
Really the only snag I’ve run into so far is with “OmniGraffle”:http://www.omnigroup.com/applications/omnigraffle/ files. When you add images to an OmniGraffle drawing, it creates an OS X bundle (essentially a directory) with the images and other associated files. This creates problems for svn since files-as-directories is a bit outside their concept of a file system. The biggest problem, though, is an icon file in the bundle with a carriage return in the filename. Subversion didn’t like that at all.
Luckily, the fix was simple. The OmniGroup is aware of this issue and
built a secret preference into OmniGraffle to save flat files,
“here’s the detailed info”:http://blog.omnigroup.com/2006/11/02/q-a-omni-answers-take-three/.
Essentially the command to enable this is:
defaults write com.omnigroup.OmniGraffle PrivateGraffleFlatFile 0
or
defaults write com.omnigroup.OmniGrafflePro PrivateGraffleFlatFile 0
While searching around for the fix for this problem, I found a site which had a few more tips for OS X svn users. There are some lines at the end of that page to add to the svn config file to make sure common file types are imported correctly.
Also, here’s one last tip. There are probably many files you wouldn’t want to keep under version control. For example, LaTeX generates lots of files, such as .aux, .log, and .bbl, and it’s silly to check these in to svn. But it’s annoying to type svn status and see the ? by these files. The solution is set the svn:ignore property for the directory. To do this, create a temporary text file (let’s call it temp) with the following contents:
*.aux
*.log
*.bbl
then execute the following command:
svn propset svn:ignore . -F temp
After this fix, only the files you care about are checked in to svn and svn will know not to bug you about the files you don’t care about.