I first posted about the development of Subversion back on June 21, 2000, but I didn’t start using it for real until it was released this year. For the past few months, I’ve applied it to a project that I’m getting paid actual money to work on, and thusfar, I’ve been extremely impressed. I’m the only person using the repository, and until this weekend I was just doing basic check in and check out stuff.
Subversion employs the Perforce model for these operations in that it batches all of the changes together and treats them as a single, numbered transaction (unlike CVS, which treats each individual file operation as its own transaction). The advantage of the Subversion/Perforce model is that if I check in three files together to fix one bug, I can easily roll back that change as a single operation. It also makes the revision log for the repository a lot saner.
Anyway, we had an interim release of the project, and the time came to make a tag for that release. I needed to do some serious refactoring and I also needed to preserve the ability to apply bug fixes to the released version of the code so it was time to either apply a tag or branch the code. In CVS that’s the choice I would have had to make, anyway. (In CVS, tags are just markers you can add to a specific revision of a file, while branches are distinct copies of a directory structure that maintain a relationship with the structure they were branched from so that you can merge changes between them.) Subversion makes things much easier — there’s one operation,
svn copy. To make a tag or branch, you just copy your directory to another location and start working on the code there. Subversion keeps track of the relationship between the copy and the parent so you can merge changes between them.
I had actually screwed things up because I just checked in my projects from Eclipse at the top level of my repository instead of making the directories
branches. This meant I didn’t have any good place to put the copy that represented my tag when I created it. So I created new top level directories in my repository with the names I just mentioned, and then copied the top level directories into
trunk. At that point I copied
trunk into a directory in
release-1.0. Then I checked everything back out of Subversion from the new trunk. Easy as pie.
The only thing I really wish for right now is a good way to shuffle between branches in Eclipse. Maybe there’s a solution for this that I don’t know about right now, but what I’m thinking I’m going to do is create separate workspaces for the trunk and for any other branch I’m working in. The only problem there is whether to version control my workspace metadata (in other words, my Eclipse settings) or just copy my workspace directory and delete all the projects before checking out from the new branch.
Overall, I recommend Subversion very highly. The only reason not to use it is if you rely on some tools that integrate with another version control system but haven’t been adapted to Subversion yet. For example, ViewCVS is a nice tool for providing Web access to CVS, and there’s not a version for Subversion yet, although it looks like one is in the works.