Den ons 28 dec. 2022 kl 08:48 skrev Branko Čibej <br...@apache.org>:
> On 27.12.2022 02:56, Karl Fogel wrote: > > Now, how hard would this be to actually implement? The > pristineless-format WC upgrade is an opportunity to make other format > changes, but I'd hate to block the release of pristineless working copies > on this... > > > 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. > Evgeny has a point that when going from 31 to 32, we know that all pristines are there and we can rehash them in place. If/when we create format X with the new XYZ-hash, we either have to download all missing pristines or we have to support multiple hashes for each file. I've been thinking about this question and while I don't know all background, it seems to be two different questions: - Detecting changes in the WC. Karl has an excellent scenario where this might be a problem, but switching to a new hash only makes this scenario more expensive. Thus: What is the definition of "expensive enough"? I believe this is a different way of asking the same question posed by DanielSh about the criteria for a new hash. - Storing files with hash collisions. Subversion prevents this (with E160067) and as far as I understand this is because of r1794611 (by Stefan Sperling) and the log message argues: [[[ However, similar problems still exist in (at least) the RA layer and the working copy. Until those are fixed, rejecting content which causes a hash collision is the safest approach and avoids the undesired consequences of storing such content. ]]] 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? Kind regards, Daniel Sahlberg
