Jonathan Lange's busted Subverision repository.

A little background here. Jonathan Lange hopped onto IRC yesterday
with a tale of woe. He'd had this sequence of events (in his own words):

   1. Used debian unstable subversion package out of the box to create
      repos. Version unknown - probably 0.14.0, maybe 0.14.1. System
      date on the directory is 2002-07-16
   2. Upgraded debian package to latest (0.14.3-1)
   3. Got weird errors when trying to access repos, both by file and http.
   4. Asked for help on #svn
   5. Got 0.14.0 tarball, built that statically, and tried to dump. Failed.
   6. Thus commences the battle against the undead mutant skeleton hordes.

Jonathan's dump started out fine, but died at revision 79 with a
'malformed node revision skeleton'.

<donottrythisathome> Assuming the worst, I guided him in backing up
his repos, db_dump'ing his 'strings' table, removing all instances of
the offending file from the directory entries lists stored there. We
db_load'ed a new 'strings' table from the edited dumpfile,
db_recover'ed, and tried to svnadmin dump again. </donottrythisathome>

 This time, failure in revision 82. At this point Jonathan had to
leave, and I had to do other things, so he mailed me a tarball of his
repos and the above recipe, and called it a day.

Last night, Jonathan told me that he had been able to dump his
repository (finally) after grabbing the 0.14.1 tarball. Great news, but:

   jml@mumak.net (Jonathan M. Lange) writes:
>>> I am still very much interested in understanding what this is all
>>> about, and why this fixes the problem.

Well, I think I figured it out. Quoting from our CHANGES file now
(lines removed for brevity)

   Version 0.14.1 [Alpha Interim 1] (released 9 August 2002, revision 2927)
    Developer-visible changes:
    * integrated the delta-combiner! (issue #531)
    * new "skip-deltas" added to delta-combiner

I looked at a dump of the nodes table again, and sure enough, the some
of the skels looked like they had the optional skip-delta data in
them. So, my guess is that the original debian package Jonathan used
was from closer to 0.14.1 than 0.14.0. Which explains why 0.14.0
wasn't working.

The rest of this mail is just an academic exercise (sit back and learn
something about Subversion DB file hacking, kids).

--
I grepped the nodes table dump for the nodes which had the skip-delta
information in them.  Since it was optional, nodes that didn't have
this information would look exactly like an older 0.14.0 Subversion
would expect.  Hence the delayed failure.  Here are the nodes that had
the data:
   1f.0.6e	((dir 7 1f.0.2n 1 1) 0  i0)
   1q.g.6z	((file 7 1q.0.30 1 1) 0  2 8h)
   1t.0.6d	((file 7 1t.0.37 1 1) 0  hs)
   1t.0.6e	((file 7 1t.0.6d 1 2) 0  i3)
   1t.0.6s	((file 7 1t.0.6e 1 3) 0  jx)
   2o.0.61	((file 0  1 0) 0  gx)
   2p.0.6d	((dir 0  1 0) 0  hd)
   2p.0.6e	((dir 7 2p.0.6d 1 1) 0  hx)
   2p.0.6n	((dir 7 2p.0.6e 1 2) 0  iw)
   2p.0.6r	((dir 7 2p.0.6n 1 3) 0  jj)
   2p.0.73	((dir 7 2p.0.6r 1 4) 0  lo)
   2p.0.79	((dir 7 2p.0.73 1 5) 0  mt)
   2q.0.6d	((file 0  1 0) 0  he)
   2q.0.6e	((file 7 2q.0.6d 1 1) 0  hy)
   2q.0.6n	((file 7 2q.0.6e 1 2) 0  ix)
   2q.0.73	((file 7 2q.0.6n 1 3) 0  lp)
   2t.0.6d	((file 0  1 0) 0  ho)
   2u.0.6d	((file 0  1 0) 0  hq)
   2u.0.6e	((file 7 2u.0.6d 1 1) 0  i2)
   2u.0.6n	((file 7 2u.0.6e 1 2) 0  j2)
   2u.0.6r	((file 7 2u.0.6n 1 3) 0  jk)
   2u.0.73	((file 7 2u.0.6r 1 4) 0  lw)
   2v.0.6d	((file 0  1 0) 0  hu)
   2v.0.6n	((file 7 2v.0.6d 1 1) 0  j4)
   2v.0.6r	((file 7 2v.0.6n 1 2) 0  jl)
   2v.0.73	((file 7 2v.0.6r 1 3) 0  ly)
   2w.0.6e	((file 0  1 0) 0  i1)
   2x.0.6e	((file 0  1 0) 0  i4)
   2y.0.6n	((file 0  1 0) 0  iz)
   2z.0.6n	((file 0  1 0) 0  j3)
   30.0.6q	((file 0  1 0) 0  jg)
   30.0.6t	((file 7 30.0.6q 1 1) 0  k6)
   31.0.6t	((dir 0  1 0) 0  k3)
   31.0.73	((dir 7 31.0.6t 1 1) 0  m2)
   32.0.6t	((file 0  1 0) 0  k4)
   33.0.6w	((dir 0  1 0) 0  ki)
   33.0.6z	((dir 7 33.0.6w 1 1) 0  l1)
   33.0.70	((dir 7 33.0.6z 1 2) 0  l7)
   33.0.72	((dir 7 33.0.70 1 3) 0  le)
   33.0.73	((dir 7 33.0.72 1 4) 0  lj)
   33.0.74	((dir 7 33.0.73 1 5) 0  m6)
   33.0.77	((dir 7 33.0.74 1 6) 0  me)
   34.0.6w	((file 0  1 0) 0  kk)
   35.0.6z	((dir 0  1 0) 0  l2)
   35.0.72	((dir 7 35.0.6z 1 1) 0  lf)
   35.0.73	((dir 7 35.0.72 1 2) 0  lk)
   35.0.74	((dir 7 35.0.73 1 3) 0  m7)
   36.0.71	((dir 0  1 0) 0  la)
   36.0.73	((dir 7 36.0.71 1 1) 0  ll)
   37.0.71	((file 0  1 0) 0  lb)
   37.0.73	((file 7 37.0.71 1 1) 0  lm)
   38.0.73	((file 0  1 0) 0  lt)
   39.0.73	((file 0  1 0) 0  lu)
   3a.0.73	((file 0  1 0) 0  m3)
If we sort this list by their TXN-IDs (the third digit in the 3-tuple
of the NODE-REV-ID), you get this:
   2o.0.61	((file 0  1 0) 0  gx)
   1t.0.6d	((file 7 1t.0.37 1 1) 0  hs)
   2p.0.6d	((dir 0  1 0) 0  hd)
   2q.0.6d	((file 0  1 0) 0  he)
   2t.0.6d	((file 0  1 0) 0  ho)
   2u.0.6d	((file 0  1 0) 0  hq)
   2v.0.6d	((file 0  1 0) 0  hu)
   1f.0.6e	((dir 7 1f.0.2n 1 1) 0  i0)
   1t.0.6e	((file 7 1t.0.6d 1 2) 0  i3)
   2p.0.6e	((dir 7 2p.0.6d 1 1) 0  hx)
   2q.0.6e	((file 7 2q.0.6d 1 1) 0  hy)
   2u.0.6e	((file 7 2u.0.6d 1 1) 0  i2)
   2w.0.6e	((file 0  1 0) 0  i1)
   2x.0.6e	((file 0  1 0) 0  i4)
   2p.0.6n	((dir 7 2p.0.6e 1 2) 0  iw)
   2q.0.6n	((file 7 2q.0.6e 1 2) 0  ix)
   2u.0.6n	((file 7 2u.0.6e 1 2) 0  j2)
   2v.0.6n	((file 7 2v.0.6d 1 1) 0  j4)
   2y.0.6n	((file 0  1 0) 0  iz)
   2z.0.6n	((file 0  1 0) 0  j3)
   30.0.6q	((file 0  1 0) 0  jg)
   2p.0.6r	((dir 7 2p.0.6n 1 3) 0  jj)
   2u.0.6r	((file 7 2u.0.6n 1 3) 0  jk)
   2v.0.6r	((file 7 2v.0.6n 1 2) 0  jl)
   1t.0.6s	((file 7 1t.0.6e 1 3) 0  jx)
   30.0.6t	((file 7 30.0.6q 1 1) 0  k6)
   31.0.6t	((dir 0  1 0) 0  k3)
   32.0.6t	((file 0  1 0) 0  k4)
   33.0.6w	((dir 0  1 0) 0  ki)
   34.0.6w	((file 0  1 0) 0  kk)
   33.0.6z	((dir 7 33.0.6w 1 1) 0  l1)
   35.0.6z	((dir 0  1 0) 0  l2)
   1q.g.6z	((file 7 1q.0.30 1 1) 0  2 8h)
   33.0.70	((dir 7 33.0.6z 1 2) 0  l7)
   36.0.71	((dir 0  1 0) 0  la)
   37.0.71	((file 0  1 0) 0  lb)
   33.0.72	((dir 7 33.0.70 1 3) 0  le)
   35.0.72	((dir 7 35.0.6z 1 1) 0  lf)
   31.0.73	((dir 7 31.0.6t 1 1) 0  m2)
   33.0.73	((dir 7 33.0.72 1 4) 0  lj)
   35.0.73	((dir 7 35.0.72 1 2) 0  lk)
   36.0.73	((dir 7 36.0.71 1 1) 0  ll)
   37.0.73	((file 7 37.0.71 1 1) 0  lm)
   38.0.73	((file 0  1 0) 0  lt)
   39.0.73	((file 0  1 0) 0  lu)
   2p.0.73	((dir 7 2p.0.6r 1 4) 0  lo)
   2q.0.73	((file 7 2q.0.6n 1 3) 0  lp)
   2u.0.73	((file 7 2u.0.6r 1 4) 0  lw)
   2v.0.73	((file 7 2v.0.6r 1 3) 0  ly)
   3a.0.73	((file 0  1 0) 0  m3)
   33.0.74	((dir 7 33.0.73 1 5) 0  m6)
   35.0.74	((dir 7 35.0.73 1 3) 0  m7)
   33.0.77	((dir 7 33.0.74 1 6) 0  me)
   2p.0.79	((dir 7 2p.0.73 1 5) 0  mt)
In other words, if indeed your database was created to support
skip-deltas, but your dumping version of svnadmin was not, I would
expect to see failures with at least one node in each of the following
revisions:
   61, 6d, 6e, 6n, 6q, 6r, 6s, 6t, 6w, 6z, 70, 71, 72, 73, 74, 77, 79
Finally, I looked at a dump of the revisions table to see what
revisions mapped to the above transactions:
   79, 82, 83, 84, 86, 87, 88, 89, 92, 95, 96, 97, 98, 99, 100, 103, 104
Do those first two look familiar?  :-)
I'm betting that if I'd removed the problematic file from rev. 82, the
dump would have failed on 83 -- or would have failed again at the
first of the above revisions which had neither "gl_map.py" or the
second problematic file in it (since those would be outta the mix).
--
And that, my friends, tells the sad truth about my geekiness. :-(  I
think I'll go force myself to play football or rebuild an auto engine
now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org