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

Thomas Arendsen Hein thomas at intevation.de
Mon Oct 8 05:13:02 CDT 2012


* 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 :)

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

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

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


More information about the Mercurial-devel mailing list