On Wed, Oct 6, 2010 at 6:21 AM, Julian Foad <julian.f...@wandisco.com> wrote: [snip] > Most of the 'Corrupt node-revision' errors were due to the byte-offset > part of the node-rev id being wrong. This error occurred with many > different node-rev ids. A corrupt revision contained from one to > several ids with wrong byte-offsets. Each particular node-rev id > appeared in several different revisions after the one in which it was > created, and it appeared correctly in some of them and wrongly in > others, with no discernable pattern. Every time it appeared wrongly, it > had the same wrong value, so there were only two variants of each > node-rev id: the right one and the wrong one. The byte-offset was > always fairly close to the correct value, but off by about 5 to 500 > bytes. The wrong byte-offset did not point to any special place in the > target revision file, such as the start or end of a data blob, so > svnadmin reported 'Found malformed header'.
I ran across the noderev offset being wrong for the first time just recently (well, at least in this way). I can check, but I believe the offset listed on the noderev I fixed recently was considerably off. I'm still helping out that individual with something else, so I'll check on that. > One or two 'Corrupt node-revision' errors were wrong in another way. A > directory entry reference to a subdirectory named 'X' (not its real > name) had the exact value 'dir 6-12953.0.r12953/30623'. Exactly one of > the node-revs created in r12953 was named 'X', and it was a directory at > the right path, and its node-rev id was '0-12953.0.r12953/30403'. > Therefore I concluded that that is the correct replacement. Note that > both the node-id component and the byte-offset part were wrong. Wow! I haven't seen one with both the node-id component and offset wrong. Nasty. > The 'Corrupt representation' errors were also due to a byte-offset being > wrong. The second number, '1496' in the above example, is supposed to > be the byte-offset in the revision file. Like the node-rev byte > offsets, these were typically off by a small amount. I've seen this one occasionally too, but there is almost always some other error in the file. So I'm not sure if it's the result of a single problem or more than one. :-( > I did not investigate or fix the 'Reading one svndiff window ...' error. It's been a while since I fixed one of these, but IIRC, it was because the noderep said there were X bytes of data in the delta stream, and Y bytes were actually there (where Y > X). [snip] > The script is currently split into several short files and would be > better as a single script. Or it could perhaps be incorporated into > 'fsfsverify.py' or something else. I'm certainly not opposed to this. And, I'm willing to change the license of fsfsverify to Apache, if that helps things. FWIW, I do have some changes sitting in my working copy to help cope with the new rev format. However, I think it might be better to think about doing something very different, and teach fsfsverify how to use the whole repository. I originally wrote this to help me analyze a particular rev, but I've found you really need something better when it comes to making sure you've got the right fix in place. And it would really help with things like truncating nodes revs (and truncating any references, etc) and verifying the delta streams (since we could actually regenerate the data). -John
