On Tue, Aug 31, 2010 at 05:49:03PM -0400, John Szakmeister wrote: > I can't be sure which version of SVN this occurred with (I believe it > was a very recent version), but I had a user email me the other day > about a broken revision. After taking a look, it appears that SVN > picked the right offset, the right length, and the right checksums, > but the wrong revision number. It looks like this was during a tag > operation (or a copy from a previous revision). The revision the > backend chose didn't even have a related file, and the contents > certainly were not the same.
Just a possibly related note: I've been investigating broken FSFS revisions at a customer site, which fsfsverify.py was able to fix. fsfsverify.py reported "InvalidCompressedStream" and/or "InvalidWindow" errors. I haven't found the time yet to fully dig into the problem to figure out what really happened. I do have the corrupt and fixed revision files for analysis and will try to pin-point the problem based on them. Given what I know about the scenario at the customer site, there seems to be a correlation between revprop edits and corruption of revisions, even of revisions unrelated to the revisions which received the revprop edits (though I'm not sure yet if that's really the case). Julian Foad says he's seen similar issues also possibly related to revprop edits, but it's unclear whether we're seeing the same problem. I do think there could be a long-standing bug we need to fix. In the case I saw, the server was on 1.4, but in Julian's case the server was on 1.6. Maybe you're seeing the same or a similar problem, with a presumably "very recent" server? John, if you had time for a quick IRC session where you could explain the ideas behind fsfsverify.py to me at a high level and answer questions, I'd be grateful. And I'd very much like to see its functionality inside of svnadmin verify/recover, partly because I believe that reimplementing it there would give me great insight into the problem :) Thanks, Stefan
