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
Received on 2010-09-02 12:49:12 CEST