2008-09-14 15:54:19

More notes on Subversion

I recently received a large number of comments concerning my article about our failed attempt to migrate our business processes to Subversion. I found most of them to be the rather useless attempt of a hurt mind to justify its decision; it is not very helpful to say things like ”If you cannot even get such a simple migration right, I would not trust you to do more complicated things.“ Also, criticising the use of french words in the domain name is not really on-topic.

Misperceptions

Also, it seems that some people did not read the article at all. Some of the criticism was perfectly explained inside the article itself. For example, someone said that he has the impression that we tried to run our tools developed for CVS against Subversion. However, as it was outlined clearly, we tried to rewrite tools achieving the same result for Subversion, and discovered that some features required to do this simply aren't present in Subversion.

For example, the lack of vendor branches makes it impossible to differenciate between upstream changesets and local changes, making it harder to mirror vendor trees with local changes as required. svk tries to ease this somewhat, but doesn't make it much easier since it cannot detect pulled-up changesets unless they have a special commit message. The lack of vendor specific keywords (e.g. $NetBSD$) has a similar impact.

Some of the comments were actually useful though, be it only in terms of pointing out that some of the aspects were not explained properly. For example, it appears to be true that one can indeed downgrade a single file in a directory to a specific older version. However, the way branches are implemented in Subversion makes it impossible to do this arbitrarily, since files from branches cannot easily be mixed.

cvs2svn – or not

The argument about cvs2svn also remained unresolved so far due to a lack of time. I installed the latest version of cvs2svn 2.1.1nb1 and tried to convert pkgsrc again; this is the end of the output of the process:

[…]
/home/tonnerre/src/netbsd/cvsroot/pkgsrc/x11/xxkb/patches/patch-ab,v
/home/tonnerre/src/netbsd/cvsroot/pkgsrc/x11/zenity/DESCR,v
/home/tonnerre/src/netbsd/cvsroot/pkgsrc/x11/zenity/Makefile,v
/home/tonnerre/src/netbsd/cvsroot/pkgsrc/x11/zenity/PLIST,v
/home/tonnerre/src/netbsd/cvsroot/pkgsrc/x11/zenity/distinfo,v
/home/tonnerre/src/netbsd/cvsroot/pkgsrc/x11/zenity/patches/Attic/patch-aa,v
Pass 1 complete.
===========================================================================
Error summary:
ERROR: A CVS repository cannot contain both /home/tonnerre/src/netbsd/cvsroot/pkgsrc/emulators/gxemul/patches/patch-aa,v and /home/tonnerre/src/netbsd/cvsroot/pkgsrc/emulators/gxemul/patches/Attic/patch-aa,v
Exited due to fatal error(s).

(This is the output of cvs2svn -s /home/tonnerre/src/netbsd/pkgsrc-svn /home/tonnerre/src/netbsd/cvsroot/pkgsrc)

In this light, it seems to me that the claim that cvs2svn simply works is slightly exaggerated.

Subversion checkout segfault

Also, further problems turned up with Subversion during the last week. Trying to check out a subdirectory – i.e. not the Subversion root containing all branches, tags and the trunk – resulted in a segmentation fault of the Subversion client. This problem was reproducible under NetBSD, Fedora Core 9, Ubuntu and Debian Lenny. For some reason, Debian Etch was not affected, but lacked a number of software packages we used in our product.

The segmentation fault occurred in always the same subdirectory. Asking around a bit in the Subversion community, it turned out that this was a rather frequent effect which people reported regularly in various projects. Noone was sure where it originated from, so I decided to check the integrity of the SVN tree using svnadmin verify.

It seems though that svnadmin verify does not verify the tree at all but it attempts instead to check out the specific revisions, crashing and burning in the process. So, since noone of us really has the time to debug all of this, the solution is now to do a full checkout of the entire tree and work on that.

And to all the commentors: please evaluate the usefulness of your comment before hitting the send button. I don't care to hear that you would not hire us to do complicated tasks, we have enough customers who do that already.

Audit trail

  • 24 Sep 2008 10:50:15: I received another mail from the cvs2svn maintainer, claiming that the reason for the problem I'm seeing was that the NetBSD CVS was broken. According to him, this was not a fair comparison. He quoted a suggestion to delete the attic files from the cvs2svn FAQ. I would rather keep them around though as they do contain history.

Posted by Tonnerre Lombard | Permanent link | File under: programming