Correct. #2 is moot given the rejection strategy moving forward.
On Tue, May 9, 2017 at 6:12 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name>
wrote:
> Jacek Materna wrote on Tue, May 09, 2017 at 14:39:51 +0200:
> > On Tue, May 9, 2017 at 2:12 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name>
> wrote:
> > > Jacek Materna wrote on Mon, May 08, 2017 at 10:46:39 +0200:
> > >> Team,
> > >>
> > >> I wanted to start a discussion around the FAQ (and 1.10 rls. notes)
> as it
> > >> pertains to the SHA-1 issue affecting all versions of SVN RE:
> "Continue the
> > >> 1.10 alphas?" thread.
> > >>
> > >> 1) We should bias towards pro-active mitigation of this issue in
> docs/code
> > >> as we know a real solution will likely NOT come with 1.10 after all.
> > >
> > > Agreed: a solution in code would be preferable, but whichever cases are
> > > not working as we want them to, should be documented.
> > >
> > >> 2) Consider patching 1.10 with de-duplication off by default ?
> > >
> > > What's the rationale behind this? (honest question)
> > >
> > > I can see that this would, for one, allow sha1 collisions to be
> > > committed over RA, but I'm not sure what benefit you have in mind.
> > >
> >
> > Apologize for the ambiguity. I had the representation sharing feature
> > in-mind (fsfs.conf).
> > Ideally we know we want to fix it so that it recognizes this scenario as
> > two different files and does not try to share the content.
>
> Current trunk behaves this way since r1785734/r1785754. Moreover, given
> the status of the "[PATCH] reject SHA1 collisions" thread, it seems
> likely that 1.10.0 will refuse to admit collisions into the repository
> using a FSFS-level check that's active whenever rep-sharing is.
> I assume these changes address the concern underlying your point #2?
>
> Looking forward to the revised patch.
>
> Cheers,
>
> Daniel
>
--
Jacek Materna
CTO
Assembla
210-410-7661
Received on 2017-05-10 10:52:27 CEST