Re: E130003: The XML response contains invalid XML - Follow-up

[Johan Corveleyn]

On Fri, Mar 16, 2018 at 4:57 PM, Philip Martin  wrote:
> Daniel Shahaf  writes:
>
>> Philip Martin wrote on Fri, 16 Mar 2018 13:44 +:
>>
>> Changing "0" to "48" would also have broken the  and
>>  offsets in that revision file, so how come 'verify' worked after
>> that change?
>
> In the examples he gave it looks like the root node itself is being
> edited.  That works because the change is after  but before
>  and he shows  changing as well.
>
> I guess you can get away with editing the last node in the file provided
> you also change  in the same file.

Does that also explain why the OP could repair some repositories by
simply dumping and loading them? Or would dump+load also work for
corruption-instances that are not on the root node?

>From the perspective of the recoveries done by the OP, this doesn't
seem like a "breaking corruption", since it can be recovered from
quite easily.

If that is not the case, and some unrecoverable instances remain (that
cannot be dumped+loaded), can we offer any other suggestions to
recover?

-- 
Johan

Re: Actual checksum is always different

[Johan Corveleyn]

On Thu, Mar 15, 2018 at 5:42 PM, Maksim Sokolov  wrote:
> Hello,
>
> OS: Ubuntu Server Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-116-generic x86_64)
> Server Software: svn --version
> svn, version 1.9.3 (r1718519) - this is the latest version available on
> Ubuntu servers
>
> Cliet OS: Windows 10 Pro (latest updates)
> Client Software: TortoiseSVN 1.9.727907 64-bit
> *Issue can be repeated on all computer in the office.
>
> Issue: Could you tell any idea what actual checksum is always different,
> what can cause  such a kind of checksum mismatch issue?
>
> TortoiseSVN LOG
> Error: Checksum mismatch for 'C:\Images\1000\1121.JPG':
> Error:expected:  4862e296bbacf7a6c63eded7acd4a2c1
> Error:  actual:  02ffc98c8e1302b6b6bba6d82bb6a163
>
>
> Error: Checksum mismatch for 'C:\1000\1121.JPG':
> Error:expected:  4862e296bbacf7a6c63eded7acd4a2c1
> Error:  actual:  2877743527179b2fbd035c6f8fb98a27

And you can reproduce that consistently on those same files, on all
computers in the office? Sounds pretty weird to me. I don't know any
possible causes for this.

Can you 'svnadmin verify' the repository on the server?

Apart from corruption of the repository, the only thing that comes to
mind is that something might be interfering. Either with the network
traffic (proxy, security scanner, antivirus, ...), or on the client
computers (files being munged behind svn's back).

-- 
Johan