Evgeny Kotkov <evgeny.kot...@visualsvn.com> writes: > > Now, how hard would this be to actually implement? > > To have a more or less accurate estimate, I went ahead and prepared the > first-cut implementation of an approach that makes the pristine checksum > kind configurable in a working copy. > > The current implementation passes all tests in my environment and seems to > work in practice. It is available on the branch: > > https://svn.apache.org/repos/asf/subversion/branches/pristine-checksum-kind > > The implementation on the branch allows creating working copies that use a > checksum kind other than SHA-1.
I extended the current implementation to use a dynamically salted SHA-1 checksum, rather than a SHA-1 with a statically hardcoded salt. The dynamic salt is generated during the creation of a wc.db. The implementation is available on a separate branch: https://svn.apache.org/repos/asf/subversion/branches/pristine-checksum-salt The change is a bit massive, but in the meantime I think that it should solve the potential problem without any practical drawbacks, except for the lack of the mentioned ra_serf fetch optimization. So overall I'd propose to bring this change to trunk, to improve the current state around checksum collisions in the working copy, and to also have the infrastructure for supporting different checksum kinds in place, in case we need it in the future. This change is still being blocked by a veto, but if danielsh changes his mind and if there won't be other objections, I'm ready to complete the few remaining bits and merge it to trunk. Thanks, Evgeny Kotkov
