[ Please keep the users list in cc. ] On Tue, Feb 27, 2018 at 11:38 PM, Myria <myriac...@gmail.com> wrote: > On Tue, Feb 27, 2018 at 2:22 PM, Johan Corveleyn <jcor...@gmail.com> wrote: >> On Tue, Feb 27, 2018 at 10:09 PM, Myria <myriac...@gmail.com> wrote: >>> >>> On Tue, Feb 27, 2018 at 05:54 Philip Martin <phi...@codematters.co.uk> >>> wrote: >>>> >>>> Myria <myriac...@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 >> > Both the server and my desktop system are on Subversion 1.9.7. >
-- Johan
