TextMate: No longer a reason to avoid Git

I wrote recently about my headaches using Subversion with iWork documents (“iWork hates Subversion”). The consensus from the comments was that I needed to ditch Subversion for a more modern version control system. Both Mercurial and Git were popular among commenters. (I decided on Git, incidentally. The transition was extremely smooth.)

TextMate bundle editor

One TAB reader, HG, lamented that a TextMate bundle doesn’t yet exist for Git. Consider that old news. Well, unofficially. It is currently under review within the TextMate user community, but the Git bundle has been written and is available to any TextMate user who syncs to the TextMate SVN repository.

Copy (or link) the bundle from Review/Bundles into Bundles and relaunch TextMate or Reload Bundles (under the Bundles menu), and voilà!, your copy of TextMate now supports many of Git’s version control features — in addition to every other open-source version management system on the planet.

Instructions for syncing from the TextMate SVN repository is available at the TextMate wiki.

iWork hates Subversion

Or does Subversion hate iWork? I was just hit with the iWork/SVN bug that seems to be infamous among those using the two products concurrently. The problem, essentially, is the way that iWork—Pages, Numbers, and Keynote—and Subversion store their files.

It’s well-known that, for some time, Apple has chosen to package certain files as bundles; they appear in the Finder as single files, but from the Terminal and the file system proper, they are directories. Subversion (SVN, the popular version control system), like CVS (Concurrent Versioning System—another, earlier versioning system), stores its state files containing information about the current revision, the main repository, and so forth, within special directories inside each directory under Subversion control.

I have been using SVN to manage revisions of my writing—a prudent thing, you might agree, as it is both easier and more robust than the “track changes” feature of Pages (or Microsoft Word, for that matter). However, the problem lies in those .svn subdirectories that are part of every directory under Subversion control.

When Pages (or Numbers or Keynote) saves a file, it appears to do so by completely overwriting what is already present: the .svn directory is erased in the process. Attempting to commit those changes to the central repository for safekeeping illustrates the problem:

SVN failure

Files (directories? bundles?) are therefore left high and dry, and the entire point of revision control becomes moot. Since iWork does not support built-in revision control (unlike Microsoft Office), utilities such as CVS or SVN would be the next best option—if they weren’t cut down by the file bundle notion.

Ideally, Apple would decide whether file bundles—files such as applications, plugins, and iWork files—were actually files or directories and treat them as one or the other in all cases. It seems that file bundles are here to stay in their present state, at least for the foreseeable future, however.

While there are several workarounds [1][2], perhaps the most logical solution is to migrate from Subversion to a different revision control system that does not suffer this problem, such as Mercurial, Git, or GNU arch. None of these three keeps local state information within subdirectories of the working copy.

It is unknown whether other bundle-type files are susceptible to SVN and CVS impotence.