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

Adrian Buehlmann adrian at cadifra.com
Tue Oct 2 07:13:59 CDT 2012


On 2012-10-02 11:40, 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.

I'm questioning a bit why I discuss this with you, as you are not the
one who decides this, but there we go.

Again: we've never done that before.

> - That'll give time for early adopter to catch some bug.

Again: There will be no early adopters, no one will use it. Bugs will
not be noticed until this is put as default.

And you may have noticed that the new encoding is only triggered by
paths inside the store > 120 length.

> - 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.

That's a rather unimportant detail.

> 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.

The main reason is for performance. It's almost impossible to speed up
the current hashed encoding, as we have seen (The reason being that it
is too complicated to implement the current hashed encoding in C).

FWIW, I may not be around anymore if you turn it on then. It's like
letting a bomb explode with a very long delay. Someone else will have to
fix it, if there is problem. However, this may not be that important.
The code is in good shape so that everyone else can fix it. The new
hashed encoding is a lot simpler than the old one.

The next release of Mercurial will have the non-hashed filename encoding
in C. This not without risk.

I'd rather do this repo layout change in the same release. So we can
have a *single* release which does "some important changes in the repo
path encoding".


More information about the Mercurial-devel mailing list