On 19 Jan 2023, Evgeny Kotkov wrote:
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.
The checksum kind is persisted in the settings table. Upgraded
working copies
of the older formats will have SHA-1 recorded as their pristine
checksum kind
and will continue to use it for compatibility. Newly created
working copies
of the latest format (with --compatible-version=1.15 or
--store-pristine=no),
as currently implemented, will use the new pristine checksum
kind.
Currently, as a proof-of-concept, the branch uses salted SHA-1 as
the new
pristine checksum kind. For the production-ready state, I plan
to support
using multiple new checksum types such as SHA-256. I think that
it would
be useful for future compatibility, because if we encounter any
issues with
one checksum kind, we could then switch to a different kind
without having
to change the working copy format.
One thing worth noting is that ra_serf contains a specific
optimization for
the skelta-style updates that allows skipping a GET request if
the pristine
store already contains an entry with the specified SHA-1
checksum. Switching
to a different checksum type for the pristine entries is going to
disable
that specific optimization. Re-enabling it would require an
update of the
server-side. I consider this to be out of scope for this branch.
I can complete the work on this branch and bring it to a
production-ready
state, assuming there are no objections.
This sounds great to me; thank you, Evgeny. I agree that the
server-side companion change is (or anyway can be) out-of-scope
here -- the perfect should not be the enemy of the good, etc.
Best regards,
-Karl
