David Hopkins wrote on Fri, Sep 16, 2011 at 08:30:14 +0800:
> > Here's the context in the rev file:
> > id: y-31.0-32.r192/673830
> > type: file
> > pred: y-31.0.r31/264323
> > count: 1
> > text: 162 670867 6111 52486 5117fb0964ca1a78dd97447d23452e73
> > 609f4745460d6e14860daff0803ee7024c54898c 191-5r/_m
>
> That tells you that the 6111 bytes starting at offset 670867(bytes)
into
> the r162 rev file are a representation generating a file whose
checksums
> and uniquifier are given later. See subversion/libsvn_fs_fs/structure
> for details --- basically, it's DELTA\n or PLAIN\n up through
ENDREP\n.
That's interesting. It certainly explains the "end of file" error
message
that is getting thrown, because rev 162 is only 1,506 bytes long.
Rev 162 was a deletion of a single file from a different folder in the
repo so I'd be surprised if it contained any file representations at
all.
Rev 192 is 683,471 bytes long, so it *is* long enough for a 670867 byte
offset to make sense.
> >
> > Looking at the other nearby entries, they have "text: 192 [...]"
> > instead of "text: 162 [...]". Is that likely to be the problem?
> >
>
> It's normal for r192 to contain "text: 162" if rep-sharing is enabled
or
> if you did a copy-without-textmods from r162.
>
Ok. I think rep-sharing is probably enabled because this server was
installed
using SVN 1.6, and we haven't altered the setting. (It's on by default,
yes?)
But, I can see from the CPATH which file in r192 is referencing r162
(EDGE.CSV), and that reference doesn't make sense.
The history of EDGE.CSV is as follows:
R31: EDGE.CSV added to repo
R32: one of the directories in EDGE.CSV's parent path was renamed
(R162: a single file in a completely different part of the repo was
deleted.
Literally the only part of their file path in common was the repo root
folder. EDGE.CSV and the deleted file have no shared history,
relationships,
or even data in common - one is a CSV file and the deleted file was a
binary
archive!)
R192: EDGE.CSV was modified, along with several other files in the same
folder.
I've now checked, and every single other text: field in R192 references
R192.
There are no other revisions referenced.
R335: EDGE.CSV was deleted. This is because that file wasn't very
important,
and all the other files which changed in r192 were updated in later
revisions
and apparently can be successfully checked out/updated.
> > > To answer your question: yes, most definitely a copy of the r192
> > (and/or
> > > r162) rev file would allow to pinpoint the problem, however you
might
> > > not want to share those files on a public list as they may contain
> > > sensitive data (versioned file contents).
> >
> > I'll find out if I can release the broken revisions in their
entirety.
> >
>
> Perhaps someone would be willing to have a look at those two revision
> files privately.
>
> (In fact, I might be able to do this too. But I'm reluctant to make
> a promise or commitment about this.)
>
> > The corrupted revision doesn't actually contain anything
particularly
> > important (almost all the modified files in it have since been
replaced
> > by newer versions anyway). Can I fix the repository by dumping every
> > revision except 192, and then reloading the good revisions into a
new
> > repo? Or will cause problems for the revisions after 192 since one
of
> > the revisions no longer exists?
> >
>
> That won't work if files after r192 are stored as deltas against the
> fulltext of r192.
>
Hmm, ok.
I'm thinking about making a copy of the repository folder, and seeing
what
happens if I replace "text: 162" with "text: 192" in revs\0\192, since
the
offsets appear to pass the "smell test" for file size. Is there _any_
chance
that that will work? Or are there other references I would also need to
patch
inside the revs\0\192 file?
I thought I'd try doing an svndump and then use svndumpfilter to exclude
EDGE.CSV, since it seems to be the only thing with an invalid rev
reference,
but the svnadmin dump operation fails when it gets to r192, since it
can't
process the reference to r162 either.
Regards,
David Hopkins
Serck Controls
===== PRIVACY AND CONFIDENTIALITY NOTICE =====
The information contained in this message is intended for the named recipient only. It may contain privileged and confidential information. If you are not the intended recipient, you must not copy, distribute, take any action in reliance on it, or disclose any details of the message to any person, firm or corporation. If you have received this message in error, please notify the sender immediately by reply e-mail and delete all copies of this transmission together with any attachments.
The views or opinions expressed in this e-mail or any attachment are not necessarily those of Serck Controls Pty Ltd.
NOTE - You should carry out your own virus checks before opening any attachment.
Received on 2011-09-16 07:06:46 CEST