« Alpine Car Stereo + Ipod | Main | HOWTO: Java 5 on Mac OS X 10.4 Tiger »
March 28, 2005
Subversive thoughts on Subversion
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.Main Features
Compared to CVS, my usual RCS, Subversion offers some major new features:Atomic Commits
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.Problems
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.Apache SSL
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.Updates
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.Checksum Error
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.Server Corruption
One file got corrupted on the Subversion server and had to be recreated.IntelliJ Support
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.Recommendation
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.Posted by gluck at March 28, 2005 04:10 PM
Comments
Posted by: Anthony Williams at March 30, 2005 12:27 AM
Can't speak on the IntelliJ & Apache issues. I don't use the former and use svn+ssh instead of the latter (which also solves the security issue for me). However, I've not had a single data loss problem with subversion, and I've been using it heavily for nearly two years now.
I know some people have had problems with the BDB backend, so it might be worth your while trying the FSFS alternative and see if that solves your problems.
Personally the idea of going back to CVS scares me silly :-)
Posted by: Adrian Howard at March 30, 2005 01:39 AM
Posted by: Rob at March 30, 2005 10:51 AM
We've been using subversion and it's been nothing but a breath of fresh air when compared to CVS. I'd like to comment on a few of your issues.
Security: This is just an option, if you don't want subversion to store your authentication credentials, then change your preferences.
Just change the following setting in ~/.subversion/config.
[auth] store-auth-creds = no
There is a detailed discussion about this issue here. http://svn.haxx.se/dev/archive-2005-01/0038.shtml
If you're using Windows, then the TortoiseSVN client encrypts your password.
Corruption: Using the BDB backend, the database maintains transaction logs, and something bad happens to your server (like power failure), then you the database is fully recoverable. Subversion 1.2 will include more robust BDB support including better auto-recovery. The FS backend (new in 1.1) is less susceptible to these problems, and will become the default backend in the 1.2 release.
Given the huge take-up of subversion by huge projects, I think you're a bit hasty to jump back to CVS. A few examples ....
Apache runs subversion (http://svn.apache.org/repos/asf/) with the BDB backend and currently has almost 160,000 revisions and is 6.4GB in size (http://svn.haxx.se/users/archive-2005-02/0541.shtml).
KDE are in the process of moving over and their test repository contains over 400,000 revisions! https://svn.kde.org/home/kde/trunk/
Other users include Samba, Novell (including the new Hula project).... and GCC is about to move once 1.2 is released.
SourceForge is also finally looking to provide subversion hosting. http://sourceforge.net/docman/display_doc.php?group_id=1&docid=2352#strategic_projects
With this kind of support from big name projects, I think the CVS's days are numbered....
Cheers, Matt
Posted by: Matt Doran at March 30, 2005 11:08 AM
Posted by: Kevin Dangoor at April 10, 2005 07:27 AM
Posted by: Karl Fogel at April 13, 2005 01:34 AM
I'd agree it's not ready for prime time. It screws up way too often during updates. If something goes wrong during an update it'll get confused and want you to run cleanup. Cleanup will likly fail, and then you are left high and dry. Cleanup has never resolved any problems I ran in to.
Here is an example of what just happened to me. I commited several source files from work. I get home and do a "svn update." A few of the files were read only because I only use Subversion to transfer files back and forth from work. I use source safe as my main repository. Anyway, I forgot to check things out from source safe first, and there were a bunch of files that were read only. Subversion choked:
C:\src\lib2005>svn update
U stdPortfolio.cpp
U lib2005.vcproj
U bmp.cpp
U liberty.cpp
svn: In directory ''
svn: Can't move 'bmp.cpp.tmp' to 'bmp.cpp': Access is denied.
So I make everything writeable and try again:
C:\src\lib2005>svn update
svn: Working copy '.' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
Oh ok... I need to run cleanup.... Silly me.
C:\src\lib2005>svn cleanup
svn: In directory ''
svn: Can't copy '.svn/tmp/text-base/stdPortfolio.cpp.svn-base' to 'stdPortfolio.
cpp.2.tmp': The system cannot find the file specified.
Ugh.
I am a casual user of subversion and don't really have the time or interest to learn the gory details of why it is failing. I just want to be able to type "svn update" without having to worry about making my working copy unusable.
Posted by: Matt Arrington at May 1, 2005 06:39 AM