It's curious that svn "corrupts" the repository, if that's really what they
mean, when two leaf files collide.
An index or directory colliding with a file would be more understandable.

On 26 February 2017 at 18:16, Charles Forsyth <charles.forsyth@gmail.com>
wrote:

>
> On 26 February 2017 at 17:25, Bakul Shah <bakul@bitblocks.com> wrote:
>
>> Venti is similarly corruptible, right? Since the checksum is over just
>> the content. If you downloaded https://shattered.i
>> o/static/shattered-1.pdf <https://shattered.io/static/shattered-2.pdf>
>>  and https://shattered.io/static/shattered-2.pdf, venti would lose the
>> contents of one.
>>
>
> Luckily, (a) they are both bigger than the block size usually configured,
> over which the hash is calculated, and (b) in case someone tries it, you've
> actually linked to the same file (-2.pdf) but under different names, so
> there won't be a collision by following your links. Hurrah!
>
> Venti detects a collision on the attempt to write the second copy if that
> differs from the earlier one stored (error "store collision"). The earlier
> copy is untouched (venti anyway is write-once per score).
> Fossil doesn't handle it well, because it turns up during archiving and
> ends up marking the archive attempt as failed, but it will try again.
> Meanwhile, you've got time to change fossil to check the venti error
> return for "score collision" and announce it, loudly, discarding the second
> one.
> Obviously if you care about something, make sure your version is in venti
> first! Chances are that collisions arise from naughty people tricking you
> later. Probably.
>