Friday, October 23, 2009

Split my local SVN archive

Among the years spent at IMT, my SVN repository has become bloated with many things, some of which are not directly related to the work done at Parlab. Before the group closes, I plan to release the software I wrote as open-source, and hopefully with the full SVN history of this software. This requires to split up my bloated repository into smaller units.

I tried to go the 'svnadmin dump' 'svndumpfilter' way, but this did not work due to my abuse usage of cheap copies (thank to the TortoiseSVN copy option). The 'svndumpfilter2' and 'svndumpfilter3' replacements did not work either.

svndumpfilter failed on the first revision with a copy from a non-included path

svndumpfilter2 produced a dumpfile, but displayed various errors from svnlook while running.
The dumpfile could not be exported to a repository.

svndumpilter3 seemd to process everything, but produced many strange beeps during exectution, probably caused by invalid UTF-8 interpretations of binary data (png images and so on). And I failed to find the output dumpfile :-/ Maybe clearer usage explenations from the author would have helped.

Right now, I'm trying to follow the instructions by Cott Lang at Internet Stall, who seems to have encountered the same issues I had with 'svndumpfilter*'

The target repository for sync is created by :

jamesMBpro:tempSVN james$ svnadmin create --fs-type fsfs /tempSVN/FSFS/docREP/

First, change the pre-revprop-change script (done in step 3 in Cott Lang's howto):
jamesMBpro:tempSVN james$ smultron ./FSFS/docREP/hooks/pre-revprop-change

#!/bin/sh   USER="$3"  if [ "$USER" = "syncuser" ]; then exit 0; fi  echo "Only the syncuser user may change revision properties" >&2 exit 1

and then, change the start-commit script:
jamesMBpro:tempSVN james$ smultron ./FSFS/docREP/hooks/start-commit

#!/bin/sh   USER="$2"  if [ "$USER" = "syncuser" ]; then exit 0; fi  echo "Only the syncuser user may commit new revisions" >&2 exit 1

svnsync initialization:

jamesMBpro:tempSVN james$ svnsync initialize file:///tempSVN/FSFS/docREP file:///tempSVN/svnIMTtemp/trunk/doc --sync-username syncuser --sync-password syncpwd
Copied properties for revision 0.
jamesMBpro:tempSVN james$

then, the copying in itself:

jamesMBpro:tempSVN james$ svnsync synchronize file:///tempSVN/FSFS/docREP --sync-username syncuser --sync-password syncpwd
Committed revision 1.
Copied properties for revision 1.
Committed revision 2.
Copied properties for revision 2.
Committed revision 3.
Copied properties for revision 3.
Transmitting file data ...........
Committed revision 2597.
Copied properties for revision 2597.
Transmitting file data .
Committed revision 2598.
Copied properties for revision 2598.
Transmitting file data ...
Committed revision 2599.
Copied properties for revision 2599.
jamesMBpro:tempSVN james$

Now, check the copied repository.

jamesMBpro:~ james$ cd /tempSVN/coTest/
jamesMBpro:coTest james$ mkdir docTest
jamesMBpro:coTest james$ cd docTest/
jamesMBpro:docTest james$ svn checkout file:///tempSVN/FSFS/docREP
A docREP/trunk
A docREP/trunk/doc
A docREP/trunk/doc/JMuWebsite/WebContent/default.php
A docREP/trunk/doc/JMuWebsite/WebContent/video_occlusion.php
Checked out revision 2599.
jamesMBpro:docREP james$

One potential hickup here. The synced repository has the same directory structure as the original repository had (in this case, trailing /trunk/doc/). Nevertheless, the checkout seemed to work, let's see what the log has to say.

jamesMBpro:docTest james$ cd docREP/
jamesMBpro:docREP james$ svn log
r2599 | james | 2009-10-19 19:07:33 +0200 (Mon, 19 Oct 2009) | 2 lines

+ changed website links to include thesis draft, presentations
+ fixed some of www-imt dead links
r2598 | muredubo | 2009-10-16 16:00:25 +0200 (Fri, 16 Oct 2009) | 1 line

done ?
r2597 | muredubo | 2009-10-16 15:36:45 +0200 (Fri, 16 Oct 2009) | 1 line

almost done
r4 | mtzamofing | 2004-11-26 08:39:13 +0100 (Fri, 26 Nov 2004) | 2 lines

*** empty log message ***

r3 | mtzamofing | 2004-11-25 14:59:38 +0100 (Thu, 25 Nov 2004) | 2 lines

*** empty log message ***

r2 | mtzamofing | 2004-11-25 14:38:34 +0100 (Thu, 25 Nov 2004) | 2 lines

*** empty log message ***

r1 | (no author) | 2004-11-25 14:38:34 +0100 (Thu, 25 Nov 2004) | 1 line

Standard project directories initialized by cvs2svn.
jamesMBpro:docREP james$

Building of one of the most important LaTeX document in this repository (my PhD thesis) worked flawlessly on the first try. Of course, more validation of the robustness of this copy is required, but this is encouraging.

Tuesday, October 13, 2009

Updates, Quicktime, Nvidia Quadro and BSODs

I regularly update the software on the Quad Core machine I use for development in our lab: a Dell Precision 390 with a Nvidia Quadro FX 3450 graphics card. Recently, I began experiencing problems which seemed related to the graphics card. The display would freeze indefinitely, or change to the infamous BSOD.

Sometimes upon starting or restarting the machine, the display would be garbled, as if the VGA connector wasn't properly connected (it was). On various occasions, Windows detected a corrupt disk upon restart, but the automated chkdsk seemed to always be able to fix the problem (in 30 minutes).

Remembering that the latest Windows update included an update to the Nvidia driver, I thought I had found the culprit. I foolishly tried to roll back to Dell's driver, from Dell's website.
Note that apparently Dell also provides a vintage Quadro FX3450 BIOS (v5. from 01.12.2006) ! The old driver (v84.26 from 01.11.2007) seemed to install correctly, until it asked permission to restart the machine. Upon login after the restart, the driver installation program resumed, and managed to garble the display in ways that appear quite artistic in retrospective.

One hard reboot later, I decided to let Dell's abandon-driver to rest, and proceeded to download and install NVidia newest driver.
Alas, the bluescreen problem reappeared after only a few hours. Seriously bedazzled, I did waht I should have done first, I fired MS computer management utility, to look at error logs.
And there it was, numerous warnings about paging errors, followed by critical errors attributed either to my system drive, or to iaStor.sys This got me worried about a possible failure of the hard disk drive.

I remembered that while I was updating the system through Windows update, I had selected to install the optional Intel Matrix Storage software. But had finally not activated it since the system contains only 2 hard drives, on used for WinXP, and the other one for CentOS.

To my relief, hardware failure became less likely after a quick google search turned out many disturbing links, suggesting that Dell and iaStor are a risky combination :
see in particular:
Shortly after, I stumbled on the following link :

And then, bing (no pun intented), it hit me. I had also been asked by Apple update if I wanted a new version of iTunes and Quicktime. I decided to pass on iTunes, but said Ok to Quicktime.
Note that the post linked above concerns Vista, and I'm running XP. But the message I got is that Quicktime can induce trouble with iaStor on Dell Precision 390 systems.

Since I did not need the RAID software, I first uninstalled Intel Matrix Storage. However, this did not prevent the BSODs from returning. Which suggests that this software is not responsible for the crashes I experienced.

So, I uninstalled Quicktime, and tada, the crashes stopped. For now, I'm a happy camper (without Quicktime), and I can go back to my spherical Fourier transforms for DynamicVA.
But I really hope Apple fixes wahtever is wrong with QuickTime.