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.