Re: Progress on SHA-1 fixes in patch releases?

On Thu, Mar 30, 2017 at 07:04:29PM +0200, Bert Huijben wrote:
> The server side fixes currently need a third vote for backporting. These
> fixes are nominated for 1.8.x and 1.9.x.
>
> I don’t think we can really do much more on the released versions without a
> backwards incompatible change to the working copy… And I’m still not
> convinced that we should really change the WC code just to support using
> Subversion to explicitly store collisions.

Storing the collisions in the WC without a format change is not my goal
either. I don't think anyone is trying to convince you of that.
But I think it would be good if the client did not throw errors we do
not anticipate. It could at least try to detect the situation and error
out in a reasonable way.

Has anyone tested what happens on the client side now with the FSFS
fixed applied? I did not yet find time to do so.

And does 'svnadmin dump/load' work now or is it still broken if the
SHA1-colliding PDF files are in the repository?

Should we disable ra_serf's callback for fetching content from the
pristine store instead of from the repository when SHA1 matches?
This could be done without a format change.

> On trunk there are even more problems, as Ivan committed a change that made
> us rely on sha-1 even more than before to check for local changes. I already
> pinged that thread a few times, but there is no progress there.

Yes, I agree this should be looked at.
Received on 2017-03-30 19:40:33 CEST