SVN is missing the point?
Our company was using Rational Clearcase for version control about 6 years ago. The developers decided it was way to clunky, error prone and WAY too expensive. We introduced CVS and it has been working fine for a few years now. CVS is widely known, stable and simple. I looked into using SVN a few years ago but the clients were unusable at that time. This year, the SVN discussion came to life again and some of my collegues started playing with it after I mentioned it as being a step forward from CVS.
We've been using GForge for a few weeks now as an environment to keep all the project information in one place. In the light of the migration discussion from our old environment, SVN was considered because it promised to "solve" a few things for us: * Placing a tag on a very large (3GB) repository can be very quick
* Updating the local copy takes less bandwith than with CVS, meaning improved performance when working remotely over a poor connection
* SVN claims to keep the history information when moving or renaming a file (although I think that only applies if you use an SVN client to do the rename/move)
Now that we've converted/started a few projects in SVN, we find that SVN is maybe not an improvement over CVS after all. The SVN designers have overlooked a few very important things which professional users absolutely need. We had the following problems with SVN:
* There is no default eclipse integration. The Subclipse plugin behaves erratic and buggy. Subversive comes with a few SVN adapters of which we are not sure which to pick. The developer side of the SVN/eclipse combo does not work "out of the box", which adds to setup time and therefore costs money.
* Finding all the revisions and branches of a file is hard in SVN. It requires manually browsing the repository branches and doing compares. For multiple files, this requires major knowledge of SVN and it's tools. Needless to say, that also adds to development time, and therefore costs money.
* Merging branches into the trunk is complicated and requires serious manual administration on the end user side as compared to CVS, see also previous bullet.
* trunk, branches and versions are part of the directory structure. This seems a bit odd to me, because a versioning system should not interfere with my directory structure. We had a lengthy discussion on how to call and place the "trunk", "branch" and "tag" directories. At the time it sounded good to talk about, but the more I think about it, it seems completely wrong alltogether to me. The version of a file is determined by its place in a tree? That is just plain wierd.
* branches and tags are the same thing in SVN. This means that one could modify a tagged file, and nobody would notice without manual checking. This came as a complete surprise to me. We use CVS tags to tag software versions, and do production support based on those tags.
From all the discussion and experiences with SVN on some projects, I think I need to re-think my position on SVN. It suddenly doesn't seem al that promising to me. CVS does have it flaws, but because it is fairly simple, we have simple workarounds and fixes for each of them. The bandwith problem is easier solved with a better connection, and finding the history of a renamed file can be solved by having a good comment in the odd ocasion that one needs to rename or move a file.
SVN positions itself as a CVS replacement, and it had me fooled for a while, but it is really not all that good from an end users perspective. I really don't see the point of having a revision of the whole repository state, as opposed to having a version per file. That, and the fact that a lot of the SVN promises only hold up if you use the command-line SVN client, makes SVN a very weak competitor to the widely used, accepted and stable CVS.
There are a lot of rants and flames on the net about people having problems because thy "miss atomic commits" for instance. In the past 20 years of my career, they number of problems arising from commits not being atomic was not big. Most of the problems were people doing partial commits, which they could easily also have done with SVN. Most problems are not because of a tool, but because of the humans that use it, and the natural habbit of humans of making mistakes. Atomic commits solves a theoretical problem which does not lead to big problems in CVS.
The more I think about it, SVN seems to be a nerd's implementation to a theoretical problem, whereas CVS is a pragmatic solution to a real life situation.