Two years ago I ran into a problem with my SVN filesystem and got “Could not open the requested SVN filesystem” as the front-end error.

This appears to be an annoying catch-all error for “shit is broken with your SVN, dawg.”

Last time, it was because I had SVNPath defined in my apache’s httpd.conf file instead of SVNParentPath (when I had many repos in the same root directory.) This time I did not have that problem, but I did have the same error message.

That is annoying.

After several dead-ends, the vital kernel of information came from Mr. Mike Rooney’s suggestion to go to the host server itself and run:

sudo svn ls file:///path/to/local/repo

The two important parts here are that I’m trying to access the bjorked repo from the local filesystem, so the webdav layer isn’t being retarded at me and giving me the same enigmatic error message. The second important part here is that I’m running sudo to get past possible permission problems.

That command produced the following output:

$ sudo svn ls file:///path/to/local/repo/
svn: Unable to open an ra_local session to URL
svn: Unable to open repository 'file:///path/to/local/repo/'
svn: Berkeley DB error for filesystem '/path/to/local/repo/db' while opening environment:

svn: DB_VERSION_MISMATCH: Database environment version mismatch
svn: bdb: Program version 4.6 doesn't match environment version 4.4

At this point, I used the tried and true google-the-unique-error-message technique. After googling “svn: DB_VERSION_MISMATCH: Database environment version mismatch” (including the quotation marks for an exact search), I found this blog post that solved my problem.

Here’s the punchline:

$ cd /path/to/myrepo/db
$ db4.4_checkpoint -1
$ db4.4_recover
$ db4.4_archive
$ svnlook youngest ..
$ db4.6_archive -d

BUT…

The double-punchline that screwed me for a while was the fact that the berekley db utils for 4.4 were unavailable via apt-get in modern times. Thankfully, long-time systems-administration bad-ass Ted Reed was here to suggest the following set of commands:

$ wget http://mirrors.kernel.org/ubuntu/pool/universe/d/db4.4/libdb4.4_4.4.20-12_i386.deb
$ wget http://mirrors.kernel.org/ubuntu/pool/universe/d/db4.4/db4.4-util_4.4.20-12_i386.deb
$ dpkg -i libdb4.4_4.4.20-12_i386.deb
$ dpkg -i db4.4-util_4.4.20-12_i386.deb

All of these commands (run as root or through sudo) grab the neccesary files from arcane places and got them installed. After that, the previous blog post’s wisdom could be applied. From there, I was a chmod, a chgrp, and a chown away from actually being able to access my old repository again.

Of course, this was about 10 hours after where I expected to grab my old repo’s contents…

Specifically the searchbox partway down the page under “Search package directories”.

Yeah, hat’s about it.

From #sancho on irc.lunarnet.org.

Hyptosis’s homepage
chrisa’s homepage

Sophia’s first tiles!
Embrace the pixels!

Sophia has been chomping at the bit to make more games. Since it’s been going on two years since I last flexed my gamemaking muscles fully, and since I rather adore Sophia, I’ve been chasing this rainbow.

I’ve been ever more intrigued by the idea of a pure html/javascript game engine of late, and have started taking existing, established tools (like mapeditor.org’s tiled) and putting them into the browser.

Here’s the result: (currently firefox-only). To fully get the pleasure, inspect elements on this example in firebug.

The idea is simple: html/js has affordances baked-in to parse xml documents. This can handle traditional map data. css sprite-sheet techniques have been used for years now, which directly mimic old tilset/vsp-style assets. Combine the two… and you have a effen map. Throw in browser optimizations for visible/hidden elements, and we should have a relatively cheap rendering method.

The above test is fairly simple: one 30×30 map, one layer. It loads instantaneously fast. It’s tiles are a single gif sized 304×144. Fairly economical. I decided to shove each of these boys into a div for now and use the background-image css spriting technique to get a “purist” tiling implementation going.

I opted against using canvas for now because I wanted to see how far I could get without it. So far so good, but I’ve not yet really stressed the system. The next jump will be to take some of my epic 6-layer maps from SotS, translate them into xml, and see how they fair in the browser.

Of the code I wrote, I suppose the “sauce” was a fairly common offset calculation. Although this sort of endeavor may not be so common in the modern age, it’s pretty commonplace to those of us who labored in 320×240 back in DOS. Get off my lawn.

var tileset = {
    tileWidth: 16,
    tileHeight: 16,
    setWidth: 304,
    setHeight: 144,

    getCoordsfromIdx : function( idx ) {
        var idx = parseInt(idx);
        idx--; //tmx is 1-based, not 0-based.  We need to sub 1 to get to a proper mapping.
        //idx--;

        var perRow = this.setWidth / this.tileWidth;

        var x = idx % perRow;
        var y = (idx / perRow);

        return [
            -(parseInt(x)*parseInt(this.tileWidth)),
            -(parseInt(y)*parseInt(this.tileHeight))
        ];
    }
}

This is converting a single tile index into two coordinates for the renderer to consume. For instance, if you want tile 2, it takes a ’2′ at the top, does some maths, and tells you that tile 2′s offset is 16 pixels in from the top-left corner, and 0 pixels down (ie, on the top row). Some strange quirks of this code: I had to decrement the idx, because Tiled’s xml format is 1-based, not 0 (ie, the first tile, the one at (0,0), is index 1, not index 0); and I negate the two numbers I return because the consumer of these coordinates is a css background-position style, and that’s how they work.

Also of note was a small hiccup when I uploaded this to my server. My sandbox had no trouble serving a .tmx file as Content-Type: text/xml, but my big-boy server threw a conniption about it. I didn’t realize that was a problem until I threw some debugger statements into the code that “should’ve just worked” and found that all of the proper stuff was in the responseText attribute, but responseXML was null. So I renamed the mapfile to .xml on the server and everything worked fine.

I guess next step, before trying to stress the system with a super macho map, is to figure out why this isn’t working in Safari/Chrome/IE/Opera/Whatever…

The most pedestrian screenshot ever. To what depths has this once-mighty work-journal fallen?

My gruedorf showings are shameful of late, and so are all of yours. The only one holding the line at this moment is Ustor. Perhaps this should be called “UstorUstor”. Or “TorUs”.

At any rate, my small token to personal projects this week is the file management section’s edit page. Woo, now you can edit your files once they exist. Necessary, and very quotidian to a web developer.

Up next on this mystical journey is the upload section’s frontpage, featuring most downloaded recently, newest files, and staff picks (aka, Demo Alarms). After that, we’re a docs section from release. At this point, I think I should screen-scrape my old site’s documentation and import all of that into a wiki. Anyone have objections?

Also I made an schema-application tool to keep track of which .sql files have been applied in what environment.  Trust me, this is useful.

So where did I go for two months, far, far away from Gruedorf?  I honestly can say I was shocked to crack open this dev folder to find the last svn log from July 10.  So wherever I went, it didn’t seem as long as it was. :(

function test_nine() {
	$$"9" = 22;
}

fails to parse.
(which is good, I suppose)

This passes:

function test_nine() {
	$n = 9;
	$$n = 22;
	$this->assertEqual($$n, 22);
}

-Andy Friesen,
of giant-communist-robots.com.