Note that I'm using subversion package 1.1.3-1.

And you're using db from testing...

And apache needs rebuilding first.

Just to add some more experience:

Subversion broke for me in what appears to be a different way (subversion 1.1.13-1) with the most recent db in current (db 4.2.52.2-2).

My problem was on the server side. The subversion server was not able to open/modify any of my repositories. I downgraded to db 4.2.52-1 and the problem was immediately fixed.

Should this be down as a separate bug or the same one?

I think that's probably a seperate bug. Though, that one I'll probably be able to fix right now.

I should mention: I tried recompiling subversion against db 4.2.52.2-2 and that didn't help.

Okay, I fought against this one for way too long tonight. Here's what I figured out:

If you go back to version 1.12 of the PKGBUILD file for db in CVS, and you update only the location of the source file (which is no longer available via http) and you rebuild the package on a current arch system, it also DOESN'T WORK.

This means either something in glibc or something in gcc is causing versions of db compiled with them to be incompatible with the compiled db package available on the Arch 0.6 distro.

This is just about the worst kind of behavior I could imagine from some c code. Either it's a honking bug somewhere in gcc or glibc or the people at sleepycat software should be skinned.

Either way, there's no good solution I can see at the moment. The incompatibility seems to have NOTHING to do with code patches from 4.2.52 to 4.2.52.2.

Ideas?

Of course, I should point out at least 1 workaround: convert your repo to fsfs format. My fsfs format repos work fine throughout.

But it still means that any db you created with the old compiled version of 4.52.2 might well not be readable with the newly compiled version of 4.52.2.x.

Ew.

I'll be sure to do a database dump before upgrading then. For now I had fixed my problem by not using the db from testing, thanks to Jan de Groot for pointing this out.

I should be especially clear for all who might subsequently refer to this: Upgrading from 4.2.52 to 4.2.52.2 (or even compiling your own new 4.2.52 and upgrading to that) may break your old databases. You should dump before upgrading.

If these dbs are your subversion repositories, you should switch to fsfs, unless you have good reason not to. This will avoid these problems altogether.

At this point, my next strategy would be to do a clean install of Arch 0.6 and see how far I can upgrade gcc and glibc before compiling db 4.2.52 becomes incompatible. Not sure I have that kind of time, but we'll see.

I found the following procedure (don't remember where) for handling db upgrades, and it has worked for me.

(from the root of whatever repo)
rm -f db/log.*
svnadmin recover .

In theory, that should bring things back up.

Errr... the above method is assuming that the whatever svn you're using is compiled against that newer db version...i think.

I can verify this works. You do need the more recent version of db.

I'm closing this because it's been solved.