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.fors...@gmail.com> wrote: > > On 26 February 2017 at 17:25, Bakul Shah <ba...@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. >
