Probably worth a quick blog, while I’m waiting for the kettle to boil. I’ve not had a lot of GNOME time in the last week, except a few hours to help Danilo start setting up a new L10N server to host the translation status pages. Patience, people, these things take time. So, I guess there are a few people that would like to hear about ‘what happened to the Subversion migration?’. Well, let’s see.

It went miserably. We cut CVS off, and started the scripts. All looked good until I found an e-mail from Ross Burton explaining that someone had found that PNG images were corrupt in a gossip checkout from a recent test migration. I checked, and yes he was right. Dammit. On closer inspection, the problem was due to cvs2svn mistakenly identifying various binary files as text, and applying ‘svn:eol-style’ regardless. A quick re-migration of the gossip module on my local machine with the ‘–no-default-eol-style’ cvs2svn option, and it looked OK. I’d also found some docs that suggested using the ‘–mime-types’ option would be useful. I hadn’t spotted the MIME types option when I originally wrote the migration script, but that doesn’t mean to say it wasn’t there :) I’m on a 5-min coffee break, so I’ll spare you the researched facts.

Anyway, we decided to attempt to re-run the migration, having lost only 9 hours by this time. This was disappointing, but achievable as no commits had been taken to the resulting subversion modules that couldn’t be easily re-applied again. I went to bed after a long day (17hrs, IIRC).

I woke up on Sunday to the realisation that there was a second problem. The quick-fix (the no default EOL style switch) had fixed the broken binaries problem, but due to the lack of ‘svn:eol-style’ attributes for the text files, checkouts for non-Unix users were, well, not as they were months before when the migrated modules were available for testing. So, we pulled the plug and re-enabled CVS. I messed around for a while making sure things had rolled back successfully (documentation changes etc), and that any modules with heavy commits in Subversion were handled appropriately. Unfortunately, one module had to remain in Subversion, which will now be a black sheep until we can complete this mission.

So what went wrong? I fked up. As was pointed out to me, I hadn’t tested the results of test migrations thoroughly enough. With hindsight, my testing was so shallow as to be laughable, and for that I apologise to everyone I inconvenienced last weekend. I have the usual excuses, such as distractions from work, a pregnant girlfriend and preparations for an imminent inter-continental house-move in a couple of weeks. However, at the end of the day, I f*ed up. A good opportunity missed, and a weekend wasted. My sincerest apologies to all those I inconvenienced in the process.

But, it’s not all bad. No pain, no gain. We learned a few things. Since then, I’ve prepared a much more robust migration script which not only migrates the modules in parallel (provided the load average isn’t too high) but will also do a recursive diff of a HEAD CVS checkout compared to a subversion trunk checkout (inc binaries) and leave a ‘.diff’ file in a logging area. It will shortly also generate a static HTML report page every 30-60 seconds showing the status of all migrations done and in progress, so people can keep an eye on their module in the queue. If I get time, I might ever make it spit out a simple RSS2 feed too. I’m hoping that testing will show that we can complete the entire migration within 48 hours.

So when are we planning the next attempt? We don’t know. When we’re ready, I guess. GNOME seem to have a fairly busy release schedule anywy for a month or so, and I’ve got to move back to the UK, and go visit my UK clients and keep them all happy for a couple of weeks. Hopefully, I’ll still find enough time and space to prepare some test runs using the new script somewhere and make the results available. The scripts are in CVS (module ‘svn-migration’), please feel free to play with it and submit bug reports and patches :) n’t block unnecessarily, please contact me. However, we’re not going to announce another migration date until we’ve completed testing and had time to discuess the target hosting/platform issue.

At the moment, I have a small problem and a few minor reservations about our eventual hosting of Subversion on container.gnome.org, least of which is that my new script doesn’t run on python2.2, so I need to discuss this with the rest of the sysadmin team and see what we can do. It’s a fine piece of hardware, without doubt, but it’s platform is RHEL3, and it’s running subversion 1.2, which I heard (during the migration, from two reliable sources) is particularly resource heavy and has several bugs (apparently seen in large-scale use). I don’t profess to know the exact details (time-permitting will investigate), but I hear Subversion 1.4 is much more suitable, and I do feel that we should really be considering hosting Subversion on a more up-to-date platform. Also, with the new migration script test migrations are likely to cane the resources a whole lot more than they were during the previous test migrations. And…

The kettle’s boiled dry.