One more thing. The fact that in r162 one file was deleted *and no
files were added or changed* implies that the only new representations
in r162 would be directory representations --- it wouldn't add any
*file* representations --- so the reference to r162 in the node-rev
header (the sequence of ASCII lines of which the "text:" line is part)
is almost certainly bogus.
I'm curious to hear whether the problem was indeed that the noderev
referred to r162 instead of r192.
Daniel Shahaf wrote on Fri, Sep 16, 2011 at 15:37:11 +0300:
> Quick reply, more verbose one might follow up later.
>
> Your reply breaks the nested quoting levels, please try to avoid it, are
> you sending mail as text/plain?
>
> (more below)
>
> David Hopkins wrote on Fri, Sep 16, 2011 at 13:05:52 +0800:
> > David Hopkins wrote on Fri, Sep 16, 2011 at 08:30:14 +0800:
> > > It's normal for r192 to contain "text: 162" if rep-sharing is enabled
> > > or
> > > if you did a copy-without-textmods from r162.
> > >
> >
> > Ok. I think rep-sharing is probably enabled because this server was
> > installed
> > using SVN 1.6, and we haven't altered the setting. (It's on by default,
> > yes?)
> >
>
> Yes. See $REPOS/db/rep-cache.db
>
> > But, I can see from the CPATH which file in r192 is referencing r162
> > (EDGE.CSV), and that reference doesn't make sense.
> >
>
> 'cpath' is created path. It doesn't change in copies.
>
> > > > > To answer your question: yes, most definitely a copy of the r192
> > > > > (and/or r162) rev file would allow to pinpoint the problem,
> > > > > however you might not want to share those files on a public list
> > > > > as they may contain sensitive data (versioned file contents).
> > > >
> > > > I'll find out if I can release the broken revisions in their
> > entirety.
> > > >
> > >
> > > Perhaps someone would be willing to have a look at those two revision
> > > files privately.
> > >
> > > (In fact, I might be able to do this too. But I'm reluctant to make
> > > a promise or commitment about this.)
> > >
> > > > The corrupted revision doesn't actually contain anything
> > > > particularly important (almost all the modified files in it have
> > > > since been replaced by newer versions anyway). Can I fix the
> > > > repository by dumping every revision except 192, and then
> > > > reloading the good revisions into a new repo? Or will cause
> > > > problems for the revisions after 192 since one of the revisions no
> > > > longer exists?
> > > >
> > >
> > > That won't work if files after r192 are stored as deltas against the
> > > fulltext of r192.
> > >
> >
> > Hmm, ok.
> >
> > I'm thinking about making a copy of the repository folder, and seeing
> > what happens if I replace "text: 162" with "text: 192" in revs\0\192,
> > since the offsets appear to pass the "smell test" for file size. Is
> > there _any_ chance that that will work?
>
> I don't think I've heard of precedents of this bug, but sure, try it.
> If you want to test before doing it, use 'xxd -l 5 -s 670867 r162-rev-file',
> it should say either "DELTA" or "PLAIN" (with no trailing end of line).
>
> Also, standard practice, check your disk for hardware errors. (should
> have said that earlier, sorry)
>
> > Or are there other references
> > I would also need to patch inside the revs\0\192 file?
> >
>
> If there are they would all appear as ASCII '162'. Revision numbers are
> referred to in the text: node-revision header and sometimes in the header
> of DELTA-style reps. See
> https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure
Received on 2011-09-16 18:58:19 CEST