Subversion: pro/con

At work they used CVS before I started, but when I started working on my current project, I knew I would want better support for directory management. We mostly work in Eclipse, so I poked around for better alternatives. Subversion seems to have gained some significant momentum, so I thought I'd try it.

I live/work/breath/occasionally-eat off my laptop (Dell D610), and work from home/coffee-shops pretty regularly (gotta love startups!). SVN (aka Subversion) stores a local copy of your last check-out. This is great when working remotely. I don't need network access to review any changes I have in process currently. This has the downside of eating 2x as much disk, but disk is cheap. Overall, this is a definite win for my laptop.

I started using SVN right as the current controversy over possibly including SVN into Eclipse. There were 2 plug-ins implementing SVN support, each with different priorities: Subclipse and SubVersive. I won't go into the details, but waaayyy back then (aprox ~6 months ago), Subclipse seemed a bit less polished. It has issues with the fact that my Windows username is 'Derek' and my unix username is 'derek'. I prefer the Eclipse's CVS icons (as did the SubVersive team) over the TortoiseSVN icons. After a week of trying both, I settled on SubVersive and moved on to getting actual work done...

Then recently, I've been having all sorts of issues. I updated my Eclipse 3.2 install, and my first SVN action always failed, then the next try would give me a password dialog. The SVN Browser seemed to get particularly confused by this, and I would need to refresh the root. Then I couldn't check out a project at all. Fixing that by upgrading the SVN server somehow caused the SubVersive Commit code to get very confused.

So yesterday I disabled SubVersive and installed Subclipse. They still default to the ugly icons, but apparently you can change that (see Mark's comments on yesterday's rant). So far so good.

Overall, what are the pro/cons for SVN over CVS then?

Pros:

• Directory versioning (file renames versioned, etc)
• local baseline
• atomic commits (not having this in CVS makes requires all sorts of hacks to do Continuous Integeration aka an automated build/test system)

Cons:

• Eclipse/other-IDE integration not a solid as CVS (but it does exist and is much better than CLI or a toy weekend-project as for many other VCS)
• Server data-store is not conducive to incremental backups
• Still under very active development (= code churn = occasional bugs)
  
• CLI support on Windows is iffy (getting svn+ssh to work is a major pain in the arse, and I hate how TortoiseSVN adds the icon overlays)

You can see that my Cons list is just a wee bit longer than my Pros list. The lack of atomic commits in CVS drives me up the wall, so having that fixed is a serious Pro. They really need to address the svn+ssh Win32 CLI support. Yes, I know you can make it work. I've done it, but every time it takes me >1hr. Telling users to run a real OS doesn't solve the issue. I'd be happy with a CLI implemented in Java if that is easier than figuring how to package SSH in a way that works out of the box.

I don't have a final conclusion, yet. There are many other version control systems out there, but CVS and SVN seem to have the best tool support. VCS integration into my IDE is one of my drugs of choise (almost up there with intellisense). After using the 'Team' features of Eclipse for CVS, I really don't ever want to go back. Other VCSs don't seem to have IDE integration even to the 2nd tier level that SVN has achieved, and that is a serious mark against using anything else. Given the progress of the SVN integration into Eclipse and the heavy use in public open-source hosting sites, I expect SVN to mature quickly. For now, I'm going to continue to use it until I find some reason to rethink.

Update:

Mark and I have been conversing on email, which pushed me to give the SVN CLI setup a 2nd attempt. I took a bit more time to look at the most recent machine where I got this working before and noted that you are supposed to double all the back-slashes in your subverions config file. For those following along at home open "\Documents and Settings\%USER%\Application Data\Subversion\config" file in a text editor. Search for the commented out SSH= line and replace it with something like mine:

ssh = c:\\tools\\plink.exe -2 -l derek -i c:\\MyDocs\\derek.ppk

As I am the only really user of this machine, I moved my 'My Documents' folder to the more convenient location "\MyDocs" which is then where I store my key for automatically logging into our SVN host.

This finally got my CLI working. Suggestions for the Subversion crew:

1. in verbose mode, log the actual SSH shell commands exec-ed (local and remote).
2. ship with a copy of plink and a simpler configuration setup.. for example, try logging in, via plink, if that doesn't work present a username/password prompt... Customers will be much happier with a awkward, but working initial setup and the ability to improve it as necessary, rather than the current most-likely-broken-on-win32 situation.