Version control is one of the most important tool in the software developer toolbox. Being an intensive user of CVS, I decided to look at the next major versioning software. Last year I spend time looking and trying fully distributed system like Arch, Darcs or Monotone. These system are very interesting in their concept but still experimental and lack support in most development environement. One month ago I decided to go for Subversion for versioning my projects.
Subversion is less powerful than distributed systems but is a very good improvement over CVS. Since I use a centralized place to put my sources and than most open source projects use Subversion, it was time for me to better understanding it. I knew for a long time the main difference of Subversion over CVS like directories and tree versioning but actually the details where not so clear.
The repository is the central place where Subversion store your versionned files, generally somewhere on a server filesystem. With CVS there is also a central repository but you create a module for each of your project. A module has its own versioning, done on a per-file basis.
With Subversion, the repository can be seen as a versioned filesystem — there is no notion of module. You just create a directory for your project. It’s similar to a CVS module but not regarding version numbers. With Subversion, each time you commit a file, its the entire repository that increases its version number. When two developers working on separate projects but on the same repository commits files, the repository revision number will be global and “shared” between your projects. You won’t see a linear sequence of revision for each of your project. Coming from CVS, it’s a bit confusing.
The great thing is that you can checkout the whole repository and move your projects to different directory without loosing the history. That a lot more flexible than CVS where file organization is a nightmare.
The other thing I was not aware of was a change in the Subversion storage system. When I heard about Subversion, I read that they would use the Berkeley database for storing files instead of using the filesystem. I was a bit surprised of the choice because a database is not designed for storing files and is totally opaque to administration. But since version 1.1, Subversion support a new storage back-end using flat files. The back-end is called FSFS (whereas the database back-end is called BDB). FSFS is now the default choice and a lot more performant than BDB.
Concerning tools, Windows is well supported and it’s not the case of MacOS X where the choice is rather limited. There is a support for Xcode and Eclipse but since I don’t use these I was looking for something standalone. I finally found the following good candidates:
The first two are made with Java and the last two are made with OS X Cocoa. Unfortunately none of these tools are great. SmartSVN and RapidSVN just looks too ugly on OS X. iSVN and svnX are not friendly and buggy. However, the only one I find useable is SmartSVN so I go with it but I’m very frustrated to lack any mature tool for OS X.
