Anyone who tried to access SPDO via the subversion repo since Saturday may have run into a slight problem: namely a session that looked something like this:

ratatosk:svn sjan$ svn co http://www.evardsson.com/repos/projects/spdo/ spdo
svn: Could not open the requested SVN filesystem

I only became aware of it this morning, and I knew (almost) right away where the problem might lie. I was still able to access the repos via svn (in the internal network) and via file (from the server) but could not access them from http or https. I checked the svn version number and got this:

xxxx spdo # svn --version
svn, version 1.5.6 (r36142)
   compiled Mar 21 2009, 09:44:24

Copyright (C) 2000-2008 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

The following repository access (RA) modules are available:

* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
  - handles 'http' scheme
  - handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
  - with Cyrus SASL authentication
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme

Ok, so this version built on Saturday when I did my latest updates. So, ra_svn works, ra_local works but ra_neon does not. I recalled that neon upgraded from 0.28.3 to 0.28.4 on the same day with the warning:

  * Neon has a policy of breaking API across minor versions, this means
 * that any package that links against neon may be broken after
 * updating. They will remain broken until they are ported to the
 * new API. You can downgrade neon to the previous version by doing:
 *
 *   emerge --oneshot '<net-misc/neon-0.28'
 *
 * You may also have to downgrade any package that has already been
 * ported to the new API.

That shouldn’t be needed (downgrading earlier than 0.28) since everything was working fine with 0.28.3 so, a quick

emerge --oneshot =net-misc/neon-0.28.3

and all is right with the world again.

Buzz This Post Delicious Digg This Post Ping This Post Reddit Stumble This Post

I recently installed the openCollabNet OS X Universal binary for SVN 1.5.4 from Tigris and found something odd. I had installed the openCollabNet binary for 1.4.4 a while back, and don’t recall changing any install paths, but apparently something changed. After installing I ran svn –version and saw something that I shouldn’t have seen:

svn, version 1.4.4 (r25188)
compiled Sep 23 2007, 22:32:34

Copyright (C) 2000-2006 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

Strange, I should have seen the new 1.5.4 there. So I did a bit of digging. Everything I saw about the openCollabNet binary said it installed in /usr/local/bin, but when I ran which svn I saw /usr/bin/svn. So I looked in /usr/bin and /usr/local/bin. Sure enough, two installs in two different places. Not being one to do anything rash (like deleting svn from /usr/bin and then changing the path on all my tools that rely on it) I decided the best thing to do was fix it in a way that was reversible. So, I fired off a sudo ls (to get my password in scope in the shell) and then a simple

for i in `ls /usr/bin/svn*`; do mv /usr/bin/$i /usr/bin/$i.old && ln -sf /usr/local/bin/$i /usr/bin/$i; done

Once I had fired off that command another call to svn –version revealed the fix:

svn, version 1.5.4 (r33841)
compiled Oct 27 2008, 11:19:10

Copyright (C) 2000-2008 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

I am still a little confused as to how 1.4.4 ended up in /usr/bin while 1.5.4 went to /usr/local/bin (where it is expected to go from the openCollabNet binary installer). I wondered, did I change the install path at some point in the install? Somehow I doubt it, as that is not a change I would be likely to make. Just another little mystery for the unsolved cases file.

Buzz This Post Delicious Digg This Post Ping This Post Reddit Stumble This Post

I had a few headaches updating to WordPress 2.3. Not surprising since the category related tables were removed to make room for native tagging, and I have been relying on the Category Tagging plug-in. Ah well, after some hand sql work I was able to populate the tags to match the categories.

Now it can only get better, right? I have moved to using subversion to pull the latest stable release, so that takes a big chunk of time out of the equation, and now my tagging will happen at the time of posting, rather than being a pseudo-tag solution pulled from post categories. Or will it? I wonder if the tags tab in ScribeFire will do the trick?

We shall see.

The 3.0 version of the Google Sitemap generator seems to not be working, however, but I may have b0rked something there myself, and I will try again later.

Oh, and those sql statements?

If I remember correctly (I didn’t keep notes like I should have):

INSERT INTO wp_term_taxonomy (term_id, taxonomy, count) SELECT term_id, ‘post_tag’, count FROM wp_term_taxonomy WHERE taxonomy=’category’;

INSERT INTO wp_term_relationships (object_id, term_taxonomy_id) SELECT rel.object_id, tax.term_taxonomy_id FROM wp_term_relationships AS rel, wp_term_taxonomy AS tax, wp_term_taxonomy AS ttx WHERE rel.term_taxonomy_id=ttx.term_taxonomy_id AND ttx.term_id = tax.term_id AND tax.taxonomy=’post_tag’;

I could have brought the descriptions across from the categories, too, but I didn’t think about it until just now.

Edit: I found the issue with the site-map generator. It required a tweak to the memory limits in my php.ini :/

Buzz This Post Delicious Digg This Post Ping This Post Reddit Stumble This Post