Volume Number: 25 (2009)
Issue Number: 01
Column Tag: Source Code Management

(Avoiding) Subversion Troubles On Mac OS X

A few simple steps can help dodge big Subversion headaches

by Ryan Wilcox

Subversion is a Source Control Management system with the goal to be a better CVS. Source control is critically important when two or more programmers are working together, as it allows those programmers to modify the same file together, both making changes to different parts of the file, then Subversion will merge their changes together. Single programmers can also use this tool so ensure the highest quality code goes into their product - if you look at the differences between the code on the server and the code on the local "sandbox", if your changes reduce the quality of the code you can simply revert.

This article isn't about the basics of how to use version control. Mike Zornek of Clickable Bliss explains, with video, the most basic concepts of Subversion in a screencast at http://blog.clickablebliss.com/2006/04/26/introduction-to-subversion-screencast/. MacTech covered this topic in Vol 22, Issue 11 (aka: the November 2006 issue), focusing on Xcode 2.0's built-in Subversion tools).

The command-line Subversion 1.4 client comes with Mac OS X 10.5 ("Leopard"). For Mac OS X 10.4 and earlier there are a number of solutions, from Installer.app installers (Martin Ott's Subversion packages are highly regarded, at http://homepage.mac.com/martinott/), or Fink/MacPorts, to compiling it from source. This author just uses MacPorts: sudo port install subversion in Terminal.app)

For those more graphically inclined, there are a few Mac OS X native options. There are a number of graphical clients for the Mac: the two newest options are Versions.app (http://www.versionsapp.com/) and Cornerstone (http://www.zennaware.com/cornerstone/), but there is also ZigVersion (http://zigzig.com/) and SvnX, (http://www.lachoseinteractive.net/en/community/subversion/svnx/). Xcode also has Subversion support built into the Project window, and SCPlugin (http://scplugin.tigris.org/) hot-wires Subversion capabilities right into the Finder (similar to a Windows client call TortoiseSVN, which gives Subversion capabilities to the Windows Explorer). In addition to these OS X only clients, there are several cross-platform ones that work in Mac OS X.

This article assumes you're using the command-line Subversion client, and while it tries to touch on global Subversion concepts and settings, they haven't been tested with any graphical client.

The transition to Mac OS X brought lots of good things, and several annoying things old time Mac users never had to deal with under the classic Mac OS. One of these is a problem with Subversion: the propensity of the Finder to write invisible (dot) files, like .DS_Store. .DS_Store files aren't so bad, but the Finder also writes custom icon information in an invisible file named "Icon", where the last character in the file name is a carriage return (CR). That Mac style return in the file name plays havoc with Subversion-and will actually corrupt your repository in such a way that nobody will be able to make new commits (or checkout, or update). So we need to tell Subversion to never allow Icon files.

Subversion has an "ignore these files" feature, set via the svn:ignore property (please see the Subversion book at http://svnbook.red-bean.com/ for more information on properties, and check out the section on Ignoring Unversioned Items). However, properties only apply in the directory in which they were set-they aren't applied recursively to child directories. The system could put an icon file anywhere, so this is no good. There is another solution: the Subversion Runtime Configuration Area.

When subversion runs for the first time it creates a .subversion folder in your home folder. This holds configuration information for your user on that machine. Any settings made here will apply to every subversion operation you, as that user, make. In particular, we want the global-ignore option.

$ cd ~/.subversion
$ pico config

(Pico is easy. If you have a favorite editor go use that.)

In this config file, find the global-ignores line and uncomment it. (A comment any line that begins with a pound sign.). There can be no leading whitespace on that line (I had to trim a bit off mine.)

With that line uncommented, add Icon* to the end. The items in this line are white-space delimited, so just go to the end of the line, type a space, and append Icon*. (Icon* because, remember, the Icon file actually has a return at the end!)

If you do run into this problem, not to fear, it's solvable by ssh-ing into the Subversion server and executing a few svnadmin commands. Subversion has no way to totally nuke a file out of a repository, but we can create a new repository and actively filter out the stuff from the old repo that we don't want. It's worth noting here that svn remove just removes a file from the active line-up, but it's always there in the archives. (Except Icon files will still cause trouble in the archives, so we want to absolutely remove every last trace of it).

First, we need to dump the repository to a text file:

$ cd /path/to/your/repository
$ sudo svnadmin dump . > ~/repodump.dump

Secondly, we need to find where the Icon file is, so we can filter it out exactly. Use find, locate, or some other search mechanism on your local machine for this.

Now, for the filtering:

$ cat ~/repodump.dump | svndumpfilter exclude relative_path_to_Icon_file > ~/outDamnIconOut.dump

Two things are important here. Primarily, you must feed svndumpfilter your dump file-the path to your repository won't do. Secondarily, the exclude parameter takes a relative reference to the file. If you were in the root level of your sandbox (that is, your checked out files), it's the path you would enter to run a command on that Icon file.

svndumpadmin will report on what file it dumped, so if you don't see it, something went wrong (not the right path, perhaps??)

Now, move your old repository out of the way and use your new one, loaded with all your data except the Icon file:

$ mv /path/to/your/repository /path/to/your/repository_backup
??$ svnadmin create /path/to/your/repository
$ svnadmin load /path/to/your/repository < ~/outDamnIconOut.dump

The svndumpfilter section (found in Chapter 5 of the Subversion Manual) describes this command in depth, but this is what you need for now.

In the Mac OS X world many documents are actually packages: a cleverly disguised folder containing files. This goes into Subversion just fine: you simply need to add the bundle (which will recursively add all the files inside it), then add and remove the files inside the bundle as they are added or removed during work.

In order to make network operations fast, Subversion stores a copy of the revision (along with other meta-data), separate from the copy you see in your sandbox, on your hard drive. This means that Subversion can perform really fast diffs (without network access even!), and transmit just the differences to the server during a commit. Subversion writes a .svn folder with this copy, and other administrative information, for each folder in your sandbox. (CVS does a similar trick with "CVS" folders, so if this seems familiar, it is.

Cocoa document-based applications (or to quote from Apple's Document Based Application Overview: "When it saves a document, NSDocument creates a backup of the old file before it writes data to the new one. Backup files have the same name as the new file, but with a tilde just before the extension. Normally, if the write operation is successful, it deletes the backup file". Slightly confusing statement or not, the fact is a new file is created, with the new information, and the old version - with your oh so important .svn folder - is deleted forever.

Now, this isn't a problem for all Cocoa applications: some don't save using the normal NSDocument methods, some have a switch you can turn off this behavior with, or some explicitly work around it and keep .svn around (Omni Group products do this, as well as Interface Builder - starting with version 2.0 or so - and Xcode project files). But it can still be a problem where you don't expect it.

To see this behavior in action, all it takes is TextEdit (tested in Mac OS X 10.4 "Tiger" and Mac OS X 10.5 "Leopard"): create a file in that also has a picture in it. TextEdit will save this document as a .rtfd bundle. Now add this bundle to your repository (you don't have to commit it). Viewing the (visible and invisible) files in this bundle (via say ls �la on the command line) will reveal a .svn folder. Reopen the document in TextEdit, make and save a change, and look at the contents of that bundle again: no .svn folder! (Clear away any svn confusion at this point with an svn remove -force filename.rtfd).

The simplest way to fix this is to rename the ruined file, update (causing Subversion to re-download the file), move the .svn directories from newly downloaded file to the ruined file, delete the downloaded file, rename the ruined file back to its original name, and use svn as normal. This method should work in the most common workflow, but it's not guaranteed to work in all obscure situations.

This technique was described on the Subversion mailing list in early 2003 (http://svn.haxx.se/dev/archive-2003-02/1321.shtml), and a small Python script (called fixsvn, written by Nicholas Riley) was attached to this message (and is, thankfully, available in the mailing list archive) that does this heavy lifting for you. Use it as so:

$ python /path/to/fixsvn ruined_file.rtfd

Since it was written in 2003, before Subversion was bundled with the OS, the path to svn is possibly wrong (depending on what version of Mac OS X you're running, and how you installed Subversion, if you had to), but that is easy to fix.

A more modern script (written in 2007, by Daniel A. Sadilek, as a script and also as an Automator action!) is available at http://sadilek.blogspot.com/2007/07/restore-svn-in-keynotepages-documents.html.

There is some hope on the horizon: the Subversion group is planning the next generation of meta-data storage, which will hopefully include storing the .svn files in one central location, instead of in every folder in the working copy. Not having .svn folders in bundles would solve a great headache for people who (for right now) have to use these scripts.

Even with these two scripts, and the new meta-data storage plan, dealing with bundles in Subversion is not exactly Mac-like, as the svn client will treat your bundle just like a folder: files added by your editing application (TextEdit, Keynote, etc) to the bundle must be svn added, and files deleted by these applications (without telling Subversion first) must be deleted with svn remove whatever.file -force (so Subversion doesn't go looking for the file to "helpfully" delete it for you). There is a bug in the Subversion bug tracker on wanting to treat bundles as "opaque collections", but in this author's opinion, it doesn't have much chance of being implemented (as it is a Mac OS X specific bug on a cross-platform project). However, if you're interested in this, it may be an interesting bug to follow, via the Subversion project's bug tracker.

In one way, text files are text files, readable on any platform. In practice, the differing line ending styles of PC and Mac/Unix complicates moving text files from one platform to another. Good source code editors respect and try to save text files with their original line endings, but sometime good intentions don't work out and the file is saved with a different set of line endings.

Subversion (and the standalone tool diff) respects different line endings to one extent: it will properly display the line endings (unlike, for example, opening a text file with Mac or Unix line endings with Window's Notepad, which displays the line endings as square boxes). However, this means that (if the line endings were accidentally changed by an editor) diff will show that the entire file has changed, making it impossible to see what changed by reading the diff. Committing a file like this means that (a) you've just changed the line endings on all your colleagues, and (b) obscured what changed in that revision and (c) make any future automatic merges impossible to automate. (At least pre Subversion 1.5, where you use the svnmerge.py tool for automatic merges from one branch to another).

One way to prevent this is to always run svn diff to validate what you are committing, then fixing the line endings as you need to. Which works, but why use a manual process when you can automate it?

Subversion to the rescue, which allows you to mark a file as needing processing on the client side to make sure line endings are consistent both on the client side (making sure that the file is written out with the native line endings of the platform), and on the server side (making sure that the file is saved on the server with only one set of line endings.

As a side-note: Subversion also lets you force the saved line endings, making the svn client write out line endings in a particular format (for example, forcing Subversion to use PC line endings on a .csv file, even on Mac OS X), via the svn:eol-style property. For example:

$ svn propset svn:eol-style native whatever.file

To use this, it must be applied to every new file in the repository, which is another thing Subversion can do automatically for you via its auto-properties feature, turned on via the config file in ~/.subversion (which we edited earlier in the article to ignore Icon files). Uncomment the enable-auto-props line, any file types you wish in the auto-props section of the config file, and when a file matches the appropriate expression the property specified is automatically added to the file.

On Windows, at least with TortoiseSVN, the Subversion Config(uration) file can be edited via the Settings dialog.

Of course, all the developers in your workgroup must also have made this change.

Subversion is an extraordinarily useful tool, and essential both to allow multiple programmers to work on a project together, and to ensure the consistency and quality of a product's source code. This author suggests doing a mini code-review before every check in: reading your diffs and removing debugging/tracing lines to make sure the code is of the best quality it can be.

However, like many things, Mac OS X throws us curve balls. From invisible files written by the Finder (that make your repository error on commit or checkout/update), to applications tossing important administrative directories, to cross-platform issues, there are tons of little "gotchas" waiting around the corner. With any luck, and the techniques from this article, you'll be able to avoid subversion troubles on Mac OS X.

Subversion Book: http://svnbook.red-bean.com/

List of Subversion clients: http://subversion.tigris.org/links.html#clients

NSDocument save behavior: http://developer.apple.com/documentation/Cocoa/Conceptual/Documents/Tasks/SubclassNSDocument.html

Subversion Mailing Lists: http://subversion.tigris.org/mailing-lists.html

Subversion Opaque Collection Bug: http://subversion.tigris.org/issues/show_bug.cgi?id=707

Svnmerge.py Tool: http://www.orcaware.com/svn/wiki/Svnmerge.py

Ryan Wilcox has been using Subversion as his primary source control system for the last 5 years, and has been on both ends, both client and server admin, of a Subversion setup. He can be found at: http://www.wilcoxd.com