Long time svn user (and cvs in the dim dark days before that). Recently started using bzr but still feeling my way through a few issues with it.

If the command line is anathema to you, then I think svn is your only real option. As previously mentioned, smartsvn is a pretty good client that runs on macs (unlike tortoisesvn). As someone else already commented, you can use it in a purely local file shared mode if you don't need remote access, although if you are already running an apache serer and know how to configure it a bit, it isn't too hard to set up.

I started using svk, which is a pseudo-distributed source control system layered on top of svn, which isn't bad to use if you have to use svn but like being able to do a bunch of commits locally and then push them all up when you're ready (probably not a big issue for you).

I ended up using bzr because I had a requirement for doing a development project with a partner, and we had no access to an svn server for various reasons. With bzr, we are using a mutually accessible ftp server as our "central" repository that we push and pull our local changes to/from for each other.

The one thing I've found nice about bzr, git and mercurial is that unlike svn, which makes a ".svn" folder in each folder of your source tree, they only make one folder (".bzr", ".git", etc) in the base folder of your tree. Its one of those things that I didn't even know annoyed me until it wasn't there anymore.

If you are having trouble getting your head around svn, I would use bzr or mercurial (hg) over git unless you wanted to make your head explode.

The one think I can identify about mercurial (and git for that matter) that I like over bzr is that it uses a hash (SHA1 I think, or MD5) to identify revisions and branches, which bzr does not. I can see some extreme usefulness in that. (Unfortunately neither mercurial or git could handle a repository over only FTP, which was the deal breaker in my recent project.)

And if you go with svn, contrary to what someone else said, I wouldn't necessarily just use one big repository. I would at least use one per client. That way at least, you can easily archive off the repositories for old clients/projects without too much fuss.

And for the person asking about non-traditional uses of a source control program? I'm using bzr with a shared repository for my different eclipse installations. How's that for untraditional? I basically have four flavours of eclipse that I use for various development: java, c++, php and ruby.

So I have the classic install, which I then branch to by base version. On the base version I install all the plugins that I want on every eclipse install no matter what (viPlugin being the primary one). Then I branch off that one for each of the eclipse flavours I am using.

That way, when it comes time to load updates, I can do them as the base version, and then pull those to all the child branches easily, then let them add their own specific updates.

It also means I can easily try a new plugin or an update to something, and if it doesn't work or turns out to not be what I wanted, I can revert back to an earlier, stable version of my development tools.

[Brain dump complete]