On Friday 16 September 2005 03:31, nick vajberg wrote:
> I had the *exact* same error, but it was a test
> repository so I scraped it (testing over VPN
> actually). I suspect the backend didn't like my
> unstable network connection at the time, but I cannot
> prove that.
Interesting. I don't believe this is happenstance. We wrote offsets in the
text rep's offset area that were wrong. The svndiff blocks are all
well-formed (no invalid instructions anyways). It's very odd.
> >> Here's the dump of the node rev:
>
> Is it documented anywhere what the individual number
> for attributes like 'props' and 'text' mean? It would
> be nice to have a fsdump utility that spelled it out.
svn.collab.net/repos/svn/trunk/subversion/libsvn_fs_fs/structure
> Also, does "svnadmin recover" attempt to do anything
> with fsfs repositories?
No. 'svnadmin recover' is really just a BDB thing, and it's geared towards
fixing a wedged repository. FSFS is designed in a way that it cannot become
wedged. 'svnadmin recover' has never really help to recover from corruption
anyways. It would be very difficult to automate such an activity.
> >> In fact, there is a block starting at offset
> >> 1691 that is an exact repeat of the block at
> >> offset 1250990. Here's the kicker: the block is
> >> *exactly* 1249299 bytes in length.
>
> The real kicker beeing that 1250990-1249299 = 1691?
1691 is expected because that's the offset where the original block
begins. :-)
I should note that this repeated block immediately follows the original block
of data in the file. Right after the repeated block is the ENDREP, and the
start of the node revisions. This file is well formatted except for this
strange block that's repeated. 1249299 is very interesting because it's part
of a field that we actually wrote in the node revision.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 16 10:20:55 2005