Re: Inexcusable BDB upgrade triple blunder

After a message like that, I sort of expected a patch to our FAQ.
Do you have time to prepare one?

Thanks,
-Karl

-- 
www.collab.net  <>  CollabNet  |  Distributed Development On Demand
"Eric S. Raymond" <esr@snark.thyrsus.com> writes:
> 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
> 
-- 
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org