Subversive thoughts on Subversion

28 March, 2005 Greg Luck 7 comments

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.

Open Source none

Comments

Written by Anthony Williams about 7 years ago.

You might want to try CVSNT. It is an enhanced version of CVS, which features many improvements, including atomic commits, and binary diffs. Rename support is coming soon.
Written by Adrian Howard about 7 years ago.

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 http://svn.collab.net/repos/svn/trunk/notes/fsfs ” rel=”nofollow”>FSFS alternative and see if that solves your problems.

Personally the idea of going back to CVS scares me silly
Written by Rob about 7 years ago.

I’ve been trying to use SVN at home for personal development, but the Eclipse plugin is sorely lacking compared to CVS support in Eclipse. It seems like Subversion has a lot of potential, but its just not ready for primetime.
Written by Matt Doran about 7 years ago.
Hi,

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
Written by Kevin Dangoor about 7 years ago.

I’m coming in a bit late to this party, but I think it would be interesting to know which clients were in use when these problems occurred.
I’ve been using the command line client, and it’s been working great for me. I opted for the FSFS storage from the get-go, and it’s been running well for 3 months.
I do think it will take some time before svn clients are as robust as cvs clients. This is not surprising, given how long cvs has been around.
Written by Karl Fogel about 7 years ago.

Regarding security:
CVS also stores passwords in plain text, in the ~/.cvspass file. They don’t look like plaintext, but they are: they’re scrambled with a trivially reversible scheme (in fact I have a Perl script that unscrambles them). Subversion’s default non-public-key password storage was designed to have the same convenience/security tradeoff as CVS.
Written by Matt Arrington about 7 years ago.

When Subversion works it works great, but ….

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.