On Tue, May 9, 2017 at 12:08 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Tue, May 09, 2017 at 03:44:22PM +0000, Daniel Shahaf wrote:
> > Stefan Sperling wrote on Tue, May 09, 2017 at 15:25:23 +0200:
> > > This could be further extended by the config knob to give users a
> choice.
> > > I don't see a good way of adding such a knob in a patch release,
> though.
> >
> > Just give the knob a name that indicates it's not forward compatible?
> >
> > For illustration, if the knob in 1.10 will be called "foo", then the
> > knob in 1.9.6 could be named "SVN_NFC_foo", where the prefix stands for
> > "svn not forward compatible".
>
> For a patch release I would generally prefer a simple solution that
> does not add knobs. A fix that people can install and forget about
> is going to be appreciated the most after all the hype and worrying
> this problem has caused.
>
> And I wonder who would really want to tweak such a knob in the first place.
> People who really wish to store SHA1 collisions in their FSFS repository
> could just disable rep-sharing, couldn't they?
>
From the best I can tell we have no plan on how or when we could support
this in the working copy. I have also seen a lot of people express
interest in the hook scripts to block the sha1 collisions and not any real
conversation about wanting to fully support storing collisions. With that
in mind, why not just simplify this and say we have no plans to provide
support for supporting two files with the same sha1 and put the code in
place in 1.9.x to block this from happening. This removes the need for
people to add hooks and it solves the problem.
If and when someone can state enough of a need for storing files with the
same sha1 let them step forward with a proposal and code for how to do
this. Until then it seems like just flat out blocking this from happening
is better then a half hearted attempt to support it.
This approach does not need any knobs or hooks.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2017-05-09 18:27:45 CEST