On 28 Dec 2022, Branko Čibej wrote:
My point was that we shouldn't have to worry about format bumps
as
much any more because we have infrastructure in the client for
supporting multiple WC formats. That includes optional pristines,
different hashes, compressed pristines, etc. etc.
Thank you for the reminder -- that is indeed important here.
On 28 Dec 2022, Daniel Sahlberg wrote:
Since we need to be backwards compatible with older v1 clients,
can
this check ever be removed (before Subversion 2)?
So, while I believe f32 is a good opportunity to switch to a new
hash, what is the problem we would like to solve with a new hash?
As I said before, even if we couldn't think of a concrete problem
right now, the mere fact that a former guarantee [1] has become a
non-guarantee is enough motivation. We can't anticipate all the
problems that might arise from people being able to craft local
content that looks unmodified to Subversion. (As you implied,
r1794611 has no effect for content that is never committed to the
repository.)
Of course, my saying "This matters just through reasoning from
first principles, therefore we should fix it" would count for a
lot more if I were volunteering to fix it, which I'm not alas.
But I do think we don't need to search further for justifications.
What we already know is enough: our hash algorithm is known to be
collidable, yet what we're using it for depends on
non-collidability; therefore, switching to a better algorithm is a
good idea.
However, it needn't be a blocker for the next release, for the
reason Brane gave.
Best regards,
-Karl
[1] "Former guarantee" meaning "former guarantee for all practical
purposes", of course, since in the past there weren't ways to make
collisions happen.
