The Brad Hole

I believe I finally managed to get Subversion up and running on the Mac mini, but it wasn't without some pain. I nuked everything to do with DarwinPorts and started fresh. This seems to have given me a version of Apache2 that didn't have the nasty 64k webdav bug with 10.4.

Once I got that sorted out, I had to dump my Subversion repository from the G5 and then load it back up on a clean repository on the mini. This is where things got weird. At some point, I had checked in an invisible icon file to the SVN repository - on purpose no less. The trouble, as I discovered after I made the check-in, is that the invisible icon files have a 0x0d character as the last character of their name - this is apparently by design from Apple.

Subversion (at least version 1.1.x) allowed me to check a file in with this name, but once in the repository, really didn't like it. I got all kinds of strange unrelated errors trying to work in the repository immediately afterwards. I figured it out and deleted the Icon file from the repository (after a bit of wrangling - it's not easy to work with filenames that have a carriage return as their last character) and went along my way. In fact, I had completely forgotten about this trouble file until today.

I used Subversion 1.2.3 to dump my old repository and then re-load it on the new Mac. Here's the rub - the svnadmin tool that comes with 1.2.3 will dump everything from that repository just fine, but it refuses to deal with any filenames that have control characters in their name when it came time to load stuff back in, like my troublesome Icon file. So svnadmin would create a dump file with my old problem filename and then be unable to read it back in. I'd qualify this as a bug - it should either force you to rename the file at dump time, allow you to skip it when reloading the repo or some combo of the two. Instead, it creates a dumpfile that is essentially broken.

Well, the repository dumps that svnadmin creates are really just big honkin' text files. As it turns out, the MacMAME repository, when dumped, was a 1.8 gig text file. Some googling revealed that the solution to my problem was simply to remove the file from the dumpfile, so I figured I'd just fire up a decent text editor and have at it.

It seems not many text editors can cope with 1.8G text files. TextWrangler and BBEdit gave an error -108 (which is an old-school MacOS out of memory error) despite claiming to be able to work with text files up to 2G in size. Uh-oh. TextEdit just beach-balled for several minutes before I lost patience. CodeWarrior gave up almost immediately. Normally it'll load up large files pretty quickly, but I must've passed some internal limit. I downloaded a bunch of other text editors off the 'net, but they all pretty much choked. I tried my favorite command-line editor (pico) but it eventually failed with a "malloc" error. At this point, I started to get a little frustrated.

The Subversion docs said that you could dump the repository in binary format to keep the dump file size down. I figured this might solve my name problem if the binary dump somehow changed the way it dealt with filenames. No such luck - same error. I then read online that there was a Subversion tool - svndumpfilter - which would strip files whose name matched a certain filter out of the dump file. This sounded exactly like what I needed! Incredibly enough, svndumpfilter barfed because the version # of the dump file was 3 and it wanted 2, even though it was built and distributed as part of Subversion 1.2.3. This caused me to swear out loud *and* extend a certain finger at the screen.

After some brain-wracking, I remembered that crusty old HexEdit would edit extremely large files pretty quickly, so I fired it up. I was able to hex-edit the troublesome control character out of the dump file, and finally load it into svn. Success!

Ironically, even though HexEdit saved my bacon, I've been actively looking for a more Mac-like hex editor for a while now. And I'll have to add a decent text editor to that list too. :-)