Back in March I started sing the Subversion revision control system in anger. The experience was not totally positive, thus the title of this post. I just tried to move a project to Subversion again this week. I reverted back to CVS after a day.
Compared to CVS, my usual RCS, Subversion offers some major new features:
Commits either all succeed or all fail. This lets you avoid the scramble, trying to avoid breaking the build, when some of the files succeed and some fail.
Every Commit is a Tag
In Subversion, each time you commit, a transaction is performed against the repository and each file and directory gets a new version number.
Binary Files are First Class
Subversion knows about binary files. It can also effectively diff them. No need for -kb when you add them.
In practically using Subversion I saw many problems that are absent from CVS. I should have wrote this article earlier, because I cannot now recall the exact causes of each. While some of the points raised may be perceived as griping, I am used to CVS which is extremely reliable and mature.
We got a couple of runaway processes using https to access the repository. Not sure exactly where the problem lay. We dropped back to http, which works well.In my recent Subversion use, we had about 100MB of binaries. The server was again set up with https, this time with certificate based security. It seemed slow to import them when I set up the module. One of my colleagues waited over an hour for a checkout. After it completed we checked the server for any problems. There were no runaway processes. For some reason it was slow.
What Security? There is no security
After a successful login Subversion stores you password in plain text in the ~/.subversion/auth/ directory. Given that a lot of people (probably stupidly) tend to use the same password, or a small number of passwords, this is very dangerous. If you know someone is using Subversion, you know where there password is. I am not sure why Subersion was designed like this. The defence that the directory is accessible only by the owner, being in their home directory is extremely lame. There is now a switch to turn this off, but the default remains to store in plaintext.
One developer had a problem where he updated, got a screen full of information about updates but it had not completed. Not sure what the cause of this was. By contrast CVS will always update.
Under some circumstances, you will get a checksum error. At this point you cannot do anything but delete the file. The circumstances are: abrupt termination of the Subversion client, or a buggy subversion client. IntelliJ Irida, still in development, does this. svn cleanup does not fix the problem.
Subversion gets confused
On about three occasions, Subversion got what I can only call confused. It refused to commit or revert. These situations invariably involved deleting the directory tree in the working copy and doing an update. svn cleanup does not seem to help. Nor does svn revert.
One file got corrupted on the Subversion server and had to be recreated.
IntelliJ will fully support Subversion in version 5, codenamed Irida. It is useable now for diffs and commit browsing. Do not try to perform any adds or commits however or you will get the dreaded checksum error. Update: The new IntelliJ Irida version of IDEA supports Subversion. Given that they are getting close to release, I decided to check it out. Unfortunately a refactor involving moving files to a new package totally screwed up. Back in CVS it worked fine.
When I originally wrote this post, the number and type of problems we experienced suggest to me that Subversion is not ready for primetime just yet. Three months later, and with my reliance on IntelliJ IDEA, my opinion remains the same.
UpdateI tested IntelliJ 5 last week. It;s Subversion support is now very good. Note that they do not suport the file: protocol for local repositories as yet. Other than that no problems. I think Subversion is now ready for a look.