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

Thomas Arendsen Hein thomas at intevation.de
Thu Oct 4 03:07:37 CDT 2012


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

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

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