Thursday, January 05, 2006

Subversion vs CVS

Yesterday I trieb to setup subversion for the first time. At work we are currently managing a large project with a lot of subcomponents with CVS and Eclipse. For almost three years now everything has gone alright, however the server is getting problems now, handling the steadily growing repository.

As a first step we are going to install new, more powerful hardware, but I have been wondering for some time, if subversion would not be better for our needs. We do lots of labelling and some branches are not so uncommon, too. Considering the size of our repository (some 16GB and lots and lots of sourcecode, documentation and library files) some operations just tage ages to complete.

But what I hate most is the non-atomic commits CVS has and that you cannot see, which files were affected by a particular checkin. It very hard to get people to repeat the names of everything they touched for a commit in the checkin comment. Some developers don't even try to commit everything at once, they do it file-by-file, so even cvs2cl is only of limited use, because the timestamps vary for a single changeset.

Having not too much work between the holidays and the new year I spent some time to setup a subversion 1.2.3 server on an already present Debian system. I chose to use the Apache (svn_dav) based variant and the file system based storage backend ("fsfs") because I think I could not sleep well, knowing that the whole of our project depends on the "well-being" of a BDB database. That's the main reason we did not consider subversion when we started our project, because back then this was the only option you had and the prospect of losing everything due to a corrupt database file was not soo appealing to us.

The other major criteria that has to be met is integration into Eclipse. Because most of our developers are not too much interested in the inner workings of a revision control system, they would not accept anything less comfortable than the current Eclipse CVS integration. And one has to admit that this a very fine piece of software, indeed.

So I installed subclipse from the subversion homepage into my Eclipse 3.1. I did not take another look at any documentation, just to make sure I get the "feeling" right and act as if I still had CVS under my hands. I connected to the repository without problems, except for a lower-case drive letter in my workspace path that subclipse complained about. Then I created a simple Java project and a Hello World class. Sharing the project, i. e. putting it under version control worked quite ok and all the familiar markers and icons were put to Eclipses package explorer view.

Then I tried to get place a currently updated revision history view to my perspective. This alone worked without problems. What I did not manage to get was the automatic update. Even though I checked the "Sync with Editor" option, I did not get the list of revisions of the file currently open in the active editor. Clicking the refresh-view button did not work either. So I looked at the new icons in the views toolbar and clicked on "get all". This actually showed me the single revision of the file (or: the single revision of the repository that particular file state was in) I expected. I wondered for a moment, why the lowest revision number shown was "2", even though I had added the file in one single operation with sharing the whole project. So just out of curiosity I clicked on the "next 25 revisions" button, just the be confronted with an ugly message dialog, complaining about a "path not present" error. However on another machine I do not even see that button, so maybe I just a pre-release of the plugin. I will see to that again next week, now it's time get ready for the new year's eve party...

No comments: