On Tue, Feb 27, 2018 at 10:09 PM, Myria <myriachan_at_gmail.com> wrote:
>
> On Tue, Feb 27, 2018 at 05:54 Philip Martin <philip_at_codematters.co.uk>
> wrote:
>>
>> Myria <myriachan_at_gmail.com> writes:
>>
>> > -bash-4.1$ sqlite3 rep-cache.db "select * from rep_cache where
>> > hash='db11617ef1454332336e00abc311d44bc698f3b3'"
>> > db11617ef1454332336e00abc311d44bc698f3b3|604440|34|134255|136680
>> >
>> > The line from the grep -a command containing that hash is below. They
>> > all match.
>> > text: 604440 34 134255 136680 c9f4fabc4d093612fece03c339401058
>> > db11617ef1454332336e00abc311d44bc698f3b3 604439-cyqm/_13
>>
>> The rep-cache looks correct. There doesn't seem to be any corruption in
>> the repository: you confirmed that you could retreive the revision in
>> question, and that you could verify the revision, and the rep-cache
>> looks OK. So why is the commit that attempts to reuse the data in the
>> revision failing? I don't know :-(
>>
>> > In other news, unknown whether related to the current problem, my
>> > attempt to clone the repository to my local computer is failing:
>> >
>> > D:\>svnsync sync file:///d:/svnclone
>> > Transmitting file data
>> >
>> > .....................................................................................................................................................svnsync:
>> > E160000: SHA1 of reps '227170 153 193 57465
>> > bb52be764a04d511ebb06e1889910dcf
>> > e6291ab119036eb783d0136afccdb3b445867364 227184-4vap/_4o' and '-1 0
>> > 193 57465 bb52be764a04d511ebb06e1889910dcf
>> > e6291ab119036eb783d0136afccdb3b445867364 227184-4vap/_4o' matches
>> > (e6291ab119036eb783d0136afccdb3b445867364) but contents differ
>> > svnsync: E160004: Filesystem is corrupt
>> > svnsync: E200014: Checksum mismatch while reading representation:
>> > expected: bb52be764a04d511ebb06e1889910dcf
>> > actual: 80a10d37de91cadc604ba30e379651b3
>> >
>> > This is odd, because revision 227185 (the revision it's trying to
>> > commit) verifies fine on the originating server:
>>
>> That's an error committing to the new repository on your local machine,
>> i.e. the problem is in the new repository not the repository on the
>> originating server. Can you run "svnadmin verify" on the new
>> repository? You may want to use -M to increase the cache size for the
>> verify command as the default is small.
>>
>> It would be odd for svnsync to create a corrupt repository, so I half
>> expect verify to report no problems. If that is the case it seems to be
>> the original pproblem again: an apparently valid repository with a
>> checksum error only on commit. So this problem is happening on two
>> repositories, on two machines with different OS.
>
>
> Not to mention that the two revisions complained about are unrelated, and
> 2/3 the repository history apart.
>
> One thing that's interesting is that the commit the svnsync failed on is a
> gigantic commit. It's 1.8 GB. Maybe that svnsync is failing because of a
> Subversion bug with huge files...?
>
> I started an svnadmin verify on my incomplete local copy last night, and no
> problems were reported when it finished this morning. I'll try again with
> this -M option you mention.
>
> I'll also start an svnsync from a Linux machine.
>
> I'm going to see how hard it would be to just copy the 43 GB repository
> directly. We'd have to shut down Subversion service during the copy, so it
> might be a while before I have a chance to.
What version of SVN server are you using actually? AFAICS you never
mentioned this.
I'm wondering whether this is related to the bug that was fixed for 1.8.x here:
http://svn.apache.org/viewvc?view=revision&revision=1803435
... or a similar problem.
I'm actually not sure whether that bugfix was released already (it's
not mentioned in CHANGES).
See also the users@ thread it references (an false positive of a SHA-1
collision occurred during 'svnadmin load'):
https://lists.apache.org/thread.html/b475d74442bdf93b21c8656ab2289b4c61e0d90efdafc8a16ddca694@%3Cusers.subversion.apache.org%3E
OTOH there was also another report of a SHA-1 collision during
'svnadmin load', this time with 1.9.7. We never got to the bottom of
that one either:
https://svn.haxx.se/users/archive-2018-01/0062.shtml
--
Johan
Received on 2018-02-27 23:23:15 CET