Oh, sure. Ask us questions that get us dreaming of the perfect app.

Introduce Unison (which I love, combined with the surplus storage at DreamHost makes a good backup/sync) as a great tool, profess your love.

Tell us you’ve temporarily abandoned it for something better, but then be unable to tell us anything about it due to NDA.

Cruel, cruel.

People new to subversion (or who don’t want to do much tinkering with the command line) can take advantage of this Finder plug-in to have full access to the commands from within the comfort of the Finder. I haven’t personally tried it out, but I’ve heard good things about it. If you’re really new, you’ll probably want to read up on just what it is with this subversion book.

This makes it easy to use subversion from outside of the command line, but I don’t know if it has some sort of Applescript interface (I’m pretty sure it doesn’t) for automating updates or commits.

I find it useful to update and commit manually rather than at regular intervals (just helps to reduce conflicts if I’m editing the file on more than one machine), but I can’t imagine it to be too hard to automate the process using a shell script.

If you have a repository checked out at ~/college101/, then you can use this small shell script to automate the update and commit from the server:

cd ~/college101/
svn update
svn commit -m "Scheduled update."

Save this script, and add it to your crontab, and you should be set. My word of caution is that if you check out the repository onto multiple machines, and tend to edit similar files, you may start running into conflicts on those files. Remember to commit and update regularly without the script as well.

You can also use cron or hook scripts with SVN to do various powerful backup-related tasks. For example, store a hot-backup every hour, or dump the latest revision in text form with each and every commit. Semi-painful to set up, but if that ain’t automation…

The main thing I don’t like about syncing with Subversion is that it forces you to put up with .svn folders everywhere. It is a bit unwieldy for this type of application.

I have used subversion for years. It’s great for automated backup and synching of a tightly integrated group of files that don’t change too much, like all the files in a coding project. But it’s a bad choice for general synching because of its fussy handling of file creation/deletion and because of its incompatibilities with subtleties of the OSX file system. There are three main problems:

1) SVN requires special workflow for adding and deleting files.

As long as you’re only modifying files in a predefined set, SVN requires little handholding. You just do an “update” command at the beginning of your work session and a “commit” command at the end. But if you want to create a new file, or delete an old one, it is not enough to create or delete it in the Finder. You need to issue an explicit “add” or “delete” command to subversion. The same is true every time you create or delete a directory.

2) SVN isn’t aware of bundles.

The last issue becomes a real pain when you also consider that SVN is unaware of file bundles. A lot of files in OS X are in fact directories, which the Finder presents as a single file. But SVN just sees it as a directory. So what happens when a file within the pseudo-file bundle is created or deleted? Then SVN requires you to go inside the file bundle and do the explicit add or delete command on the files within. This is a common problem with apps like OmniOutliner, that use file bundles for their document format.

The workaround is to always compress the bundle into a zip file or a dmg, and then handle that through SVN, but this is a nuisance.

3) SVN obliterates metadata

SVN was designed for a standard unix filesystem like ext2, and so it loses a lot of the metadata that is unique to the HFS+ filesystem used by OS X — extended attributes (used by apps like Skim.app), resource forks (I think), ACL’s, etc.. This isn’t always a big deal. But it’s one more thing to worry about.