This is the first of my mini-articles about why I made the infrastructural choices that I did on my current personal project. Practically every choice involved leaving the comfort zone, learning new things, adding extra time and thrash to the project. So far, in every case I feel good about the choice, despite the extra overhead.
Why did I choose Subversion for my source control system, when I had the old reliable CVS easily available? For one, I wanted some experience in it. The project is rolling forward and seems to be approaching something very good, so I wanted to get some experience using it. I had built some trivial repositories and worked with it enough to feel comfortable. Once I had established a baseline that I was reasonably confident it wouldn’t eat my history, it had a few things that actually made it better for this project than CVS.
Chief amongst those features is the ability to move files within the repositories easily. Directories are versioned objects in Subversion, which is unlike CVS. One of the worst aspects of CVS is that the pain of moving files once established encourages one to stick with bad directory layout. I really didn’t have a good feel for what kind of directory layout I wanted, and in fact I have changed it many times since I began. In CVS, each one of these would be an ordeal and if I were to back up to a version prior to the current layout, it would be a nightmare just to get the files in the proper places. With Subversion, this is automatic. A move is just another operation, and when you call down version X, you get the file structure as it existed in version X, regardless of what changes existed before or after that point. This is a seemingly small change in functionality, but it has a huge impact on functionality and usability of an SCM.
Another thing that made this worth pursuing was the existence of the Subclipse plugin for Eclipse. I use both the CVS and Subversion Eclipse plugins every day and its easy enough to forget which one you are using. They are mostly look-alikes and almost complete act-alikes. Subclipse actually provides a little more information on each file, with the version number in which they last changed and the timestamp showing in the package explorer view. Otherwise, they both have the same commit and update functions. Both are equally easy to use.
Thus far, I’m happy with my choice of Subversion. Sometimes on one person projects, the developer either uses no SCM or seldom uses it. In my case I am developing on multiple computers, which sort of emulates having multiple developers, but also gives me many points at which I check in. Everytime I move from box to box, I commit on the old one and update on the new one. This leads to many saved states of development, and allows me ample opportunity to compare across versions when I know that functionality behaved properly at some point and doesn’t now. I have used it to pull down previous checkin points and generally used it exactly as I would have for CVS. By adding in the ability to refactor my directory and package structure, that makes Subversion a clear winner for my needs.
