Introducing a new fncache2 entry in .hg/requires or not and how to possibly do it

[Adrian Buehlmann]

(Previous subject was: "[PATCH 11 of 11 V1] store: implement new fncache2 requirement",
in thread http://mercurial.markmail.org/thread/rpwmxuxwul4kcdc4)

On 2012-10-04 10:07, Thomas Arendsen Hein wrote:
> * Matt Mackall <mpm at selenic.com> [20121002 23:07]:
>> 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.
> 
> For us not major, but only because I disable new formats for some
> time in installations I do.
> 
> Some people access repositories from more than one machine, either
> via network file systems (NFS, CIFS, ...) or removable media (USB
> sticks), and not all machines are upgraded on the same time.
> 
>>> I do not advocate to turn it off forever. I advertise to turn it off for a few version.
> 
> Ideally I would say that we should make sure that Debian backports
> can read Mercurial stable, but that will probably cause more delays
> than would be good for Mercurial's development.

[..]

> As a compromise I would suggest to turn it off for one major
> release, that's only a three-month delay, but at least allows the
> stable release to read everything that the development version can
> write and, maybe even more important, allows the previous stable
> release to read everything that the current stable can.

Having thought about this some more, I think that would be acceptable.

The code for fncache2 repositories would however be mostly unused for
three months, except for the testcases we have in the testsuite.

As soon es the new format is in the main repo, we however will have to
support it forever. Because a couple of users may already have started
to use it for some cloned repos. Even though it was not released yet.

>> 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.
> 
> I think this discussion is not about who is right and who is wrong,
> because both sides have valid arguments.
> 
>> 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.
> 
> +1 on this part.

I just gave up again on reviewing "hashmangle" in C. The complexity is so
depressing. The fault is not in the C code, the complexity is in the
current fncache repo format already.

Perhaps someone else may be motivated and able to review it and take
responsibility for all the repos users already may have. The challenge
is to assert that both the C and the current Python code are 100%
equivalent.

If a project or company would newly introduce Mercurial and the only code
path used there would be the new C code, they'd probably wouldn't worry
that much.

Others who are aware of the situation might run all their repos through
verify before upgrading everyone in the team to use the new C code.

The rest of users will be hit by the full risk, as the new C code would
be inflicted on them without a repo format change - no separation. So they
will shoot into their current clones using the new C code, with all the
bugs it may have.