David Hopkins wrote on Mon, Sep 19, 2011 at 10:06:17 +0800:
> > Daniel Shahaf wrote:
> > 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.
>
> Sadly, it wasn't. I've now experimented with that. The offset supposedly
> within r162 is listed as 670867 bytes, which is well outside the total
> length of r162 as we've already discussed. But it isn't a valid pointer
> within r192 either; offset 670867 points to the middle of one of the
> other rep blocks within the r192 file. I've had a look at the other
> node-rev headers and it appears that all the rep blocks in the r192 file
> are fully accounted for by the node-revs which have text: 192. (That is,
> there are no representations in the r192 file which don't already have a
> valid node-rev header).
>
So the question is whether the rep is lost or just misplaced.
> I've had a look through all the revs between 162 and 192 which are at
> least 600 KiB in size. But I can't find *any* rev files in the whole
> repository history leading up to 192 where an offset of 670867 points to
> the beginning of a DELTA or PLAIN representation.
>
> So, I'm now assuming that both the reference to r162, and the offset of
> 670867 bytes, are bogus. But there aren't any obvious candidates for a
> non-bogus representation of that particular file update.
>
Okay. FWIW, there is no easy way to find an orphaned/unreferenced rep
in the revision files. The rightest way would be to parse all node-ids
(which _is_ possible, think 'svn ls -R'), collect all the rep pointers
they contain, then see if there are any additional reps. And even then,
identifying their length would have to be done manually... (reps do not
contain their own length)
> Given that the file with the bogus node-rev is unimportant, and has
> since been deleted from the repo, is there any way to patch the r192
> rev-file so that the repository has enough internal consistency to
> produce a valid dump file?
>
I suppose you could do it in a number of ways, either by changing what
rep the node-rev refers to or by unlinking the node-rev from its parent.
Be careful about successors of the file --- whether new revision of the
file are expressed as deltas to the node-rev which is now corrupted.
You must know whether that's the case before deciding how to alter that
node-rev.
Also, you must cause no offsets in existing rev files to change (so, add
padding as needed). And probably a few other things that I forget right
now...
> At the moment it looks like the "nuclear option" is to check out the
> current version of everything and start a new repository with it. This
> *should* work because the corrupted file isn't included in recent
> revisions, so SVN won't need to de-reference the invalid reference in
> r192 when performing the check out. But if I can purge the broken-ness
> from the repo and keep the rest of the history, that would obviously be
> better. I certainly don't want to keep using a repo that doesn't
> validate and can't be dumped, though.
>
You ought to be able to keep the rest of the history even without fixing
the brokenness in r192. (as the file is deleted in HEAD, a checkout
should work; and you also have the option of dumping the history while
excluding the problematic file from it (via authz+svnsync/svnrdump or svndumpfilter).)
> >
> > 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?
> > >
>
> Sorry about breaking the nested quoting. I'm using Outlook which is
> pretty mediocre as a plain-text email client. I was already using
> text/plain, but Outlook's quoting style wasn't right, so I was trying to
> manually fix the text-wrapping and quote marks. Clearly I wasn't getting
> it right. I've now found a couple more Outlook settings which will
> hopefully address the problem.
>
Thanks, much better now.
> Unfortunately, it doesn't look like I'll be able to send you the actual
> rev file(s), at least not without a lot of inconvenience that I don't
> want to subject you to (ie an NDA, since we don't actually own the IP to
> any of the code which may be included in the rev file). Sorry about
> that.
>
No problems, and good luck.
If you need docs about the FS that 'structure' doesn't have, they would
be under ../libsvn_fs_base/.
> Regards,
>
> David Hopkins
>
Received on 2011-09-19 13:27:36 CEST