SubversionFS: a possible solution to the badging problem!

One of the big problems we, the developers of SCPlugin, are still encountering until today is to display the correct state of all the files and folders under Subversion's control. This is also known as badging. Below, you can see an example of how this is displayed in the Finder. This screenshot comes from the SCPlugin website.

To give the user the proper information on what the state is of every file and/or folder, we use overlays on the default Mac OS X icon set. The calculation of the correct state is quite easy.

The problem we do have is to make sure that the badging can start from the moment the user logs in. SCPlugin consists of the contextual menu item (the popup menu) together with a background process. Every action selected in the popup menu results in an AppleEvent sent to the background process. Currently, the background process is started once the first action is selected from the popup menu. This means that the badging is incomplete in the beginning and often not consistent once started. The implementation of getting the badge on top of the regular icon is also not quite bullet proof.

Since I have a few weeks to fill due to a ski accident, I had time to learn and explore more of Mac programming. So I read lots of documentation on how a number of the Mac internals fit together. After that, I searched the net for other software that tried to differentiate from the regular Mac icon set. It didn't take me long to find the following project:

MacFUSE

This project is a port of the regular FUSE code to Mac OS X, brought to us by Amit Singh, the author of Mac OS X Internals. I started with looking at the video MacFUSE Tech Demos that explained the power of displaying different information throught the file system concept. After that, I started thinking...

Getting the badging right!

To get the badging right from the first moment, SCPlugin should be able to provide all file/folder information to the Finder instead of hacking in the badging somewhere from the sideline. So, why not provide Subversioned files as a separate file system under Mac OS X?

Let me explain with some screenshots how a complete installation and usage cycle of SubversionFS, the next SCPlugin could work! Note however that what you see below is nothing more but graphics and fancy Photoshop-ing! No real code behind it!

As with all software, the user first has to download the disk image containing Subversion FS and mount it.

Installing the contents is as easy as dragging the reference panel from the disk image to the PreferencePanes folder. If you use /Library/PreferencePanes, it is installed for all users, if you use ~/Library/PreferencePanes, it is installed only for the current user.

Now unmount the installer disk image. Once that is done, we enter the usage part of SubversionFS. However, we must first configure and activate the file system. Open the System Preferences.

Open the SubversionFS preference panel, enter a mount point and press the Install button. So what is this mount point all about? The Subversion file system displays itself as a separate disk in the Finder, but eventually, the files that you checkout from different Subversion repositories need to be stored somewhere. This mount point indicates the folder wherein all your Subversioned files will reside.

After installation, the Remove button will become enabled in case you want to stop using SubversionFS. (You must be out of your mind to stop using SubversionFS! :-)

When the installation succeeded, you will have a SubversionFS disk image mounted. From there, you can continue using the contextual menu item. This contextual menu item will only be displayed within the SubversionFS file system to offer a consistent user experience.

So far for the user experience...

What about the development aspects involved? Well, the MacFUSE team released and Objective-C wrapper around the core MacFUSE libraries. This means that the whole filesystem code and icon manipulation can be done completely in an object-oriented fashion. Besides that, all the code should be easily unit testable. Because of the use of a PreferencePane, we have clear points where the daemon should start and stop. Initially, the Install button creates an alias for the contextual menu item in the required user folder, makes sure the moint point exists, starts the background daemon that offers the Subversion file system and registers it as a Login Item for the current user. The Remove button just does the opposite.

Let's discuss further on the scplugin developer mailing list!

Ringo