Inexcusable BDB upgrade triple blunder

Once before I flamed the Subversion dev group over an unbelievable sequence of
blunders, slipshod programming, and culpable obliviousness to the situation
of actual users. Looks like it's time I have to do it again, and once again
the botch combines a broken administrative procedure with pathetically
inadequate documentation and an alleged recovery path that's a mirage.

Yes, this means I've tripped over the 4.2->4.3 BDB upgrade problem.
My symptoms:

svn: Unable to open an ra_local session to URL
svn: Unable to open repository 'file:///home/esr/WWW/shipper/SVN/trunk/README'
svn: Berkeley DB error for filesystem /home/esr/WWW/shipper/SVN/db while opening environment:
DB_VERSION_MISMATCH: Database environment version mismatch
svn: bdb: Program version 4.3 doesn't match environment version

First blunder: screwing up db_recover() so a current svnadmin can't be
used to upgrade the repository. But that would have been OK, except for...

Second blunder: the FAQ answer. Fix it with an older version of
svnadmin? Sounds like a peachy idea -- until the svnadmin run fails
because it doesn't see the right version of the SVN repo shared libraries to
dynamic-link to. A 100% predictable roadblock about which the
FAQ entry says *nothing*.

Oh, and by the way, there's that marvelously vague instruction to
'make a backup'. Why? With what? And how does one tell if one needs
to *use* the backup? In general, this FAQ entry is so dizzyingly
useless to anyone who doesn't inhabit the skull of a Subversion
developer that one is left to wonder that kind of drugs the dolt who
wrote it was on.

Here, too, the lossage could easily have been contained -- by carrying
links to downloadable statically linked svnadmin42 binaries for major
platforms in the FAQ entry. But no. That would have made too much sense.

Third blunder: Instead, diligent Googling turned up a set of recovery
instructions bypassing svnadmin and using the db* utilities. Except
that when applied on the most commonly deployed Linux distribution
(Fedora Core) the instructions don't actually, you know, *work* or
anything. I'm referring to this:

http://lists.alioth.debian.org/pipermail/pkg-subversion-maintainers/2005-November/000268.html

Buoyed up by the naive confidence that a reply I found on the
Subversion dev list itself might embody something resembling a clue, I
did as it suggested and wrote a script, intending to donate it back to
the project. Here it is:

------------------------------------------------------------------------------
#!/bin/sh
#
# Upgrade a local SVN repo from BDB 4.2. Follows the instructions in
# http://lists.alioth.debian.org/pipermail/pkg-subversion-maintainers/2005-November/000268.html
#
repo=$1

db42_checkpoint -1 -h ${repo}/db
db42_recover -h ${repo}/db
db42_archive -d -h ${repo}/db
rm ${repo}/db/__db.???
------------------------------------------------------------------------------

Notice that I couldn't actually follow the instructions, because the db utility
names weren't right. I fixed them, and ran the script, and got this:

db_checkpoint: open: No such file or directory
db_recover: Ignoring log file: SVN/db/log.0000000004: unsupported log version 10
db_recover: Invalid log file: log.0000000004: Invalid argument
db_recover: PANIC: Invalid argument
db_recover: PANIC: DB_RUNRECOVERY: Fatal error, run database recovery
db_recover: DB_ENV->open: DB_RUNRECOVERY: Fatal error, run database recovery
db_archive: Ignoring log file: SVN/db/log.0000000004: unsupported log version 10
db_archive: Invalid log file: log.0000000004: Invalid argument
db_archive: PANIC: Invalid argument
db_archive: PANIC: DB_RUNRECOVERY: Fatal error, run database recovery
db_archive: open: DB_RUNRECOVERY: Fatal error, run database recovery
rm: cannot remove `SVN/db/__db.???': No such file or directory

And yes, I did check that the repo path was correct. (It pretty much
has to be for the second error line to have been generated.)

But I should not have had to try writing a recovery script iun the
first place. I can see by the date of the aforementioned posting that
this bug has been a known problem for *three* *months*. That tells me
there is zero excuse for there not to have been a fix script
downloadable through the Subversion FAQ page and dated at least two
and a half months ago.

What in the fleeping frack were you guys *thinking*? Or, more likely,
not-thinking. It's guaranteed that this same problem is going to mug
anyone who updates from the 1.1.4 stock on FC4 to 1.2.3. You've now
left anybody who relied on your upgrade path with invisibly broken
repositories and no way out for at least *eight* *weeks*.

That's inexcusable. Whoever is responsible for this triple-play of
incompetence should be deeply ashamed. It reflects badly in the entire
dev group.

-- 
		Eric S. Raymond
In the absence of any evidence tending to show that possession 
or use of a 'shotgun having a barrel of less than eighteen inches 
in length' at this time has some reasonable relationship to the 
preservation or efficiency of a well regulated militia, we cannot 
say that the Second Amendment guarantees the right to keep and bear 
such an instrument. [...] The Militia comprised all males 
physically capable of acting in concert for the common defense.  
        -- Majority Supreme Court opinion in "U.S. vs. Miller" (1939)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org