Martin Pool's blog

Mail me RSS Bazaar distcc Canonical is hiring! flickr

Fixing log messages in Subversion

It turns out there is a way to fix commit messages in Subversion. I just didn't know it. James very kindly points out:

In your weblog post you talked about committing a revision to a Subversion repository with an incomplete log message. You can actually correct this in an SVN repo without too much trouble.

The log message is stored as a revision property, so you can print it with the following command:

svn propget svn:log --revprop -r N

It is possible to change the property with svn propset provided that a "pre-revprop-change" hook exists for the repository (the default hook is to disallow all changes, because they aren't versioned and you might not want to allow users to change them anyway). So if the hook allows it, and you have the full log message in a file, you could run the following:

svn propset svn:log --revprop -r N -F log-message-file

Despite this, I still think darcs unrecord is far more friendly, and it handles other cases than just fixing the message. I don't think I would bother doing all that (or finding out how to do it) with Subversion if I just got the message a bit wrong, but I use unrecord moderately often.

I guess there is a fundamental difference here between centralized and distributed VC: if there is just One Tree, you have to be more careful. If everyone is allowed to make a branch on their workstation then you can give them more freedom to make mistakes, and just refuse to take the changes back.

posted Fri 24 Sep 2004 in /software/vc/subversion | link

Liberal Media Bias

John Sequeira says that I write a lot about version control (which is true) and that I have a bias towards distributed version control, which is also true.

1. Distributed development is the whole point of open source. People should be able to contribute without needing prior permission; and to work with you even if they're on another continent.
2. I live in Australia, also known as the arse end of the earth. Roundtrips to the US are slow. I don't want to spend any more time waiting for CVS to open an SSH tunnel if I can possibly avoid it.
3. Version control, properly conceived, ought to offer distribution at no added cost. Andrew Morton's quilt does it in a couple of hundred lines of shell. Given you can have it for free, why not? It might be useful. The challenge is to make it sufficiently simple and reliable, but I think some new systems come close.
4. Cheap branches can be useful; distributed systems where they need never leave your workstation are a good way to get it.

I really should try Monotone (again) and Svk.

To be fair, here's what I like about Subversion:

1. It is extremely easy to learn if you're used to CVS. If you work with people who see VC as a cost, rather than a benefit, then it may be the easiest switch.
2. It fixes the most annoying parts of CVS: you can rename files, version tags, etc.
3. There is a good book, a selection of GUIs, and it runs on many platforms.

On the downside, it is a bit prone to crashing and you get something only incrementally better than CVS.

posted Tue 24 Aug 2004 in /software/vc/subversion | link

Google's opinion of Subversion

A lot of people seem to end up at my version control scribblings when asking Google for help with Subversion database crashes.

I guess I should put some content here, because mentioning this will probably increase the effect. So...

The immediate fix is to run svadmin recover /var/svn/fooproject, sigh, and get on with your life. It's gross that when Subversion is used as directed, people often need to run a operation which warns of the possibility of serious corruption of the repository.

The good news (well, less-bad news) is that although recovery is annoying, it rarely or never loses data. It just interrupts your work — possibly for a long time if you need a sysadmin's intervention.

A common cause of database crashes for svn+ssh is the permissions getting set incorrectly. (I don't understand why this isn't fixed in subversion; it shouldn't be all that hard.) If the permissions on the repository are screwed up then you might need to reset them. Typically on Unix the repository should have group set appropriately for the developers of the project, and should be g+w plus setuid directories.

The Subversion FAQ suggests that you avoid permission problems by not using Subversion over SSH, but using the Apache module or svn-over-tcp instead. I much prefer the model of using only SSH for access, but if you're on a closed network and permissions are biting hard you might want to change.

In the absence of proper handling of permissions in Subversion, you need to make sure all your users have a umask of something like umask 002 on the Subversion server. You can set this either in somewhere like /etc/profile or in a wrapper around svnserve.

If you're suffering Subversion database crashes, you're not alone! I've had it need recovery quite a number of times. Some people never get it though — I suppose it depends on how you share your repo, how often you interrupt operations and similar things.

It's good to make regular backups of your repository, just in case. We copy it several times a day, and make a complete dump of all repos every night. We also use the glorious rdiff-backup to keep snapshots of working directories going back three months.

The Subversion developers seem to acknowledge BDB crashes as a problem and are moving to a better storage system. Garrett tells me (30 seconds after I posted!)

The new non-berkeley db filesystem backend will actually be available in version 1.1 of Subversion (I use it now, and it's great), which should have it's first beta release any time now. Expect an actual release supporting the non-bdb back end in a few weeks, depending on how the beta goes.

In my personal experience Arch and Darcs don't get screwed up as often as Subversion does. (I don't pretend that my anyone else would necessarily have the same results.) I don't think the effect is so strong as to make you switch, but if you're thinking about moving from CVS to something else, you might keep that in mind.

posted Wed 14 Jul 2004 in /software/vc/subversion | link

Subversion vs Perforce

Interesting thread about Subversion compared to Perforce.

posted Fri 16 Apr 2004 in /software/vc/subversion | link

svn: Berkeley DB error

svn: Commit failed (details follow):
svn: Berkeley DB error while opening environment for filesystem /var/svn/hpsysfaultmgr/db:
DB_RUNRECOVERY: Fatal error, run database recovery

Very annoying.

posted Wed 7 Apr 2004 in /software/vc/subversion | link

Samba switches to Subversion

The Samba CIFS project has switched from CVS to Subversion. From tridge's announcement:

For those of you who weren't at the team meeting today, we decided to convert Samba development to subversion. We also decided to do it immediately, as the ideal time to convert was when most of the team was in the same room at the same time. I know this might cause some initial problems for some people, but I am sure this is going to be a worthwhile change in the long run.

We decided not to use the cvs2svn conversion tool as it just seems to have too many problems. Instead we decided to adopt the much simpler approach of starting from the current cvs code state (called "DAY_ZERO") and creating a fresh subversion repository based on an import of our current cvs branches. This means that when working with historical versions you will need to use cvs tools, and when working with diffs between dates that cross the "DAY_ZERO" boundary you will need to use 2 directories and traditional diff tools.

The current status is this:

- all cvs commits to the samba and samba4 repositories on samba.org are denied. cvs update and diff still works, but any attempt to commit will fail with an error message.

- svn over ssh is currently live. See below for brief instructions on usage

- the ~ftp/pub/unpacked/ directory has been converted to use svn, this gives us an anonymously accessible copy of the code via rsync

- cvsweb and anon cvs equivalents have not yet been completed. That is obviously a priority

- the build farm hosts should be operational with svn (they use the unpacked directory) but the "history" button on the web interface won't currently work for new svn commits. That should be fixed soon.

I think the DAY_ZERO approach is pretty sensible.

posted Wed 7 Apr 2004 in /software/vc/subversion | link

Subversion tip -- What's new?

What's new in the repository since I last updated?

$ svn log -r BASE:HEAD | less
$ svn diff -r BASE:HEAD | less

posted Thu 20 Nov 2003 in /software/vc/subversion | link

Tom Lord on Subversion

I really like Subversion. It small and simple, and the idea of write-only versioned trees is quite brilliant. I wonder now if, if you're going to go to the trouble of switching from CVS if it's worth going further afield. Unscientifically arch seems roughly as stable as Subversion, both being at about the 1.0 level.

Tom Lord gives his ideas on what went wrong with Subversion, though "went wrong" is perhaps too harsh.

That post actually is quite a good little lesson in the mistakes you can make in large-scale architecture and planning, rather along the lines of The Mythical Man-Month.

On the other side of this "unambitious" question, you can point to Linux being an architecturally unambitious reimplementation of Unix, as compared to many microkernel projects that have languished. I think almost any project does many things which in retrospect are mistakes, but even making a number of mistakes does not necessarily mean you'll fail.

Perhaps another problem with Subversion is that at the moment the performance is not stellar. Committing, for example, the entire 2.6.0 kernel source takes a long time. That would normally be entirely forgivable for a pre-1.0 project, but the write-only database is something that ought to be easy to make blindingly fast; not being so seems to indicate an abstraction inversion problem in building it on top of a read-write database.

Tom reckons leaping to adoption of W3 standards such as WebDAV was one problem for Subversion. He may be right. One problem with W3 standards is that they sometimes seem to be written with less implementation experience than IETF standards traditionally have been. Finally they seem to have admitted this after a long time and they are going to a native svn protocol over SSH, which I think is what most potential users have been asking for all along.

Subversion might also show something about the desirability of doing quick proofs of concept as Graydon has done with monotone, before deciding you've got the right solution.

Mind you I don't think Tom's posts to the Subversion mailing list were written in such a way that they could be understood. Whether you're right or not, walking in and saying "you're doing this all wrong" without details just rarely works.

What would make Subversion parallel to Linux? If it was compatible between versions; faster than CVS in 95% of cases; had a fast & easy coversion program from CVS and just simply ran over SSH then I think it would be close.

posted Sun 31 Aug 2003 in /software/vc/subversion | link

Copyright (C) 1999-2007 Martin Pool.