[PATCH 11 of 11 V1] store: implement new fncache2 requirement

[Adrian Buehlmann]

On 2012-10-02 23:07, Matt Mackall wrote:
> On Tue, 2012-10-02 at 11:40 +0200, Pierre-Yves David wrote:
>> On Mon, Oct 01, 2012 at 06:36:05PM +0200, Adrian Buehlmann wrote:
>>> On 2012-10-01 12:42, Pierre-Yves David wrote:
>>>> On Sun, Sep 30, 2012 at 11:56:48PM +0200, Adrian Buehlmann wrote:
>>>>> # HG changeset patch
>>>>> # User Adrian Buehlmann <adrian at cadifra.com>
>>>>> # Date 1349033428 -7200
>>>>> # Node ID 6a4d27efb2127f622b3a42037ae5340999c60109
>>>>> # Parent  efbc439c7f2cb97ff04ada6edd78dce186a72118
>>>>> store: implement new fncache2 requirement
>>>>>
>>>>> not yet used
>>>>
>>>> About that:
>>>>
>>>> Even if we have a much better requires message in recent version I think we
>>>> should keep this disabled by default for a few version. People who need it will
>>>> explicitly enable it and provides useful feedback before we turn is on by
>>>> default.
>>>
>>> That's not how repository layout changes have been released in the past.
>>
>> And a major source of complain from our user.
>>
>> We do not do that since 1.9 and generaldelta
>> (Ok general delta is a bit special and there are still good reasons to keep it
>> disabled for now)
>>
>>> I don't see why this one would be different.
>>>
>>> If you improve software, you need to put it to use. Otherwise it's
>>> pointless.
>>>
>>> This is not an experimental format change. It is intended as the new
>>> standard for Mercurial repositories.
>>>
>>> No user will use this format, if it's not the default.
>>
>> I do not advocate to turn it off forever. I advertise to turn it off for a few version.
>>
>> - That'll give time for early adopter to catch some bug.
>>
>> - By then we'll have much more people using at least 1.9 (eg: debian squeeze
>>   have 1.6, wheezy have 2.2)
>>
>>   1.9 have a proper error message when it encounter missing requirement. Prior
>>   to that the message is unclear and very frustrating.
>>
>> As far as I understood it, this new format mostly aims for simplification,
>> performance improvement and rare coner case handling. We are not in hurry to
>> make it the default.
> 
> Adrian's right (and he should know, having instigated the last two
> changes), that's not how we've done format changes in the past, and
> probably not how we'd deal with this transition either, if and when we
> decide to make it.
> 
> On the other hand, the only thing pushing this particular change is
> performance, so I'm in no great hurry to make a switch. I'd rather
> gather up a few more format improvements to go with it (for instance,
> dropping all the redundant data/ and .i in .hg/store/fncache). Probably
> the right time to make that decision is at the beginning of a dev cycle
> so we can have all the wrinkles ironed out. I also like to space out the
> introduction of new C code and we just added a bunch.

I'm actually perfectly fine with keeping this on the table, as long as
we don't do other ("crazy") things instead (like trying to transform the
current hashed-encoding into C).