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

[Adrian Buehlmann]

On 2012-10-08 12:13, Thomas Arendsen Hein wrote:
> * Adrian Buehlmann <adrian at cadifra.com> [20121008 11:27]:
>> (Previous subject was: "[PATCH 11 of 11 V1] store: implement new fncache2 requirement",
>> in thread http://mercurial.markmail.org/thread/rpwmxuxwul4kcdc4)
> 
> Thanks for separating this into a better thread.
> 
>> On 2012-10-04 10:07, Thomas Arendsen Hein wrote:
>>> 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.
> 
> Good :)

Has anyone read the hashmangle C code besides me or Bryan :-)

>> The code for fncache2 repositories would however be mostly unused for
>> three months, except for the testcases we have in the testsuite.
> 
> Since this code will only be used for new repositories, even
> enabling it by default would not expose it for everyone using the
> development version.

The use case which we are trying to speed up here is clone
--uncompressed over the wire. Those are new clones.

Bryan seems to care a lot about that particular use case, and he seems
to have very big repos in mind.

So those new clones would certainly get the new repo layout.

Perhaps he can explain is agenda a bit more. He certainly doesn't have
to though.

> On the other hand, if someone wants to actively test it, he could do
> so for six months with the development version or even for three
> months with the release version, if he intentionally enables it.

Those who care about this new format are just Bryan and me so far.

> Without intentionally enabling it, it would still be three months in
> the next devel cycle in addition to six months in the test suite.
> 
> Another benefit of delaying it could be that people might be more
> willing to install the devel version (or the release candidate!),
> and thus test all other new things, if it does not introduce such
> critical changes without advance testing by the people who are more
> brave.
> 
>> 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.
> 
> We dropped one experimental format in the past, recovery from this
> was easy with "hg clone --pull". I know fncache2 is not considered
> experimental, but I don't have a better name for something that
> might be considered to be dropped.

fncache2 is indeed certainly not intended to be dropped.

We can easily keep that format floating around as patches if we want for
another 6 months. Which IMHO would be roughly the same as pushing it to
the main repo and not activating it per default, except that we can drop
/ modify those patches even more easily if we want.