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

[Thomas Arendsen Hein]

* Adrian Buehlmann <adrian at cadifra.com> [20121008 14:15]:
> 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 :-)

I got a warning from you that it is not easily readable, therefore
(and of course for the real reason that I don't have time for this
now) I did not. But in general this would be something that I would
be interested to do.

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

I was more talking about people using the devel branch of Mercurial
but not intentionally testing this new feature by e.g. converting
their existing repositories with "hg clone --pull". Even if fncache2
is enabled, they only get fncache2 repos when cloning remote
repositories or creating new ones.

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

With a hint in the changelog that says "fncache2 gives better
performance with repositories with many files", I'm sure others will
try it, too. Personally I would only enable it for specific
repositories though.

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

But with this the difference would be that the code for accessing
such repos would not be in the next release, causing the problems
with interoperability I mentioned.

My suggestion about enabling it one release after including it is at
least 90% about interoperability between release and (release-1)
(or release candidate and release) and at most 10% about testing it
in the wild. Even if you find 100 people to test it for six months
before pushing it, it will cause the interoperability problems.

So I would say the best path would be to push it to crew/main
immediately after the next stable release (i.e. in less than 4
weeks) and enable it by default immediately after the stable release
after that.

Regards,
Thomas

-- 
thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner