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

Tue Oct 2 12:04:01 CDT 2012

On Tue, Oct 02, 2012 at 02:13:59PM +0200, Adrian Buehlmann wrote:
> On 2012-10-02 11:40, 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.
> > 
> > We do not do that since 1.9 and generaldelta
> > (Ok general delta is a bit special and there are still good reasons to keep it
> > disabled for now)
> > 
> >> I don't see why this one would be different.
> >>
> >> If you improve software, you need to put it to use. Otherwise it's
> >> pointless.
> >>
> >> This is not an experimental format change. It is intended as the new
> >> standard for Mercurial repositories.
> >>
> >> No user will use this format, if it's not the default.
> > 
> > I do not advocate to turn it off forever. I advertise to turn it off for a few version.
> 
> I'm questioning a bit why I discuss this with you, as you are not the
> one who decides this, but there we go.

Because I made a public objection you disagree with. We are not politely
arguing about it each trying to make our case. Ultimately to convince the other
but mainly to provide "the one who decide" with a corpus of arguments that will
help him.

> Again: we've never done that before.

And after a loads of user complaining to me about Mercurial being unusable, we
introduced a much better error message in 1.9.

pre 1.9 error message is:

    abort: missing requirement xxx

post 1.9 error message is:

     abort: unknown repository format: requires features 'xxx' (upgrade Mercurial)!

It's not a good practice but physical access to a single repo by multiple
computer is a very common use case. Because it seems logical and works in 95%
case:

- People using network share (and have other troubles),
- People using USB dongle to backup stuff,
- People moving a bunch a repo and other to a server using a big tarball,
- etc…

I also argued about enabling of general delta by default in 1.9. This was much
more easy because general delta wasn't ready by then.

I think that we *MUST* wait for 1.9+ to be more common before turning anything new by default

and 

I think we *SHOULD* always wait a few version (1 or 2) before defaulting changes that
prevent a repo created with X to be used by X-N

> > - That'll give time for early adopter to catch some bug.
> 
> Again: There will be no early adopters, no one will use it. Bugs will
> not be noticed until this is put as default.

You and Bryan will use it. And with a proper advertisement campaign you can be
sure a lot of people will turn it by default. As long as they are aware of the
consequence.

You work is good, people will use it. Just limit DVCS explode in the face of
standard user.

> And you may have noticed that the new encoding is only triggered by
> paths inside the store > 120 length.

I see this in another argument in favor of waiting. A small part of the repo
out there will benefit from the new feature. But *any* new repo will be
incompatible with the older version.

Or do we add the fncache2 requirement only if such path are present ?

> > - By then we'll have much more people using at least 1.9 (eg: debian squeeze
> >   have 1.6, wheezy have 2.2)
> > 
> >   1.9 have a proper error message when it encounter missing requirement. Prior
> >   to that the message is unclear and very frustrating.
> 
> That's a rather unimportant detail.

See above. It's very important to me. A DVCS can't be seen as unreliable.

This is the main reason I want that turn of **by default**

> > As far as I understood it, this new format mostly aims for simplification,
> > performance improvement and rare coner case handling. We are not in hurry to
> > make it the default.
> 
> The main reason is for performance. It's almost impossible to speed up
> the current hashed encoding, as we have seen (The reason being that it
> is too complicated to implement the current hashed encoding in C).
> 
> FWIW, I may not be around anymore if you turn it on then. It's like
> letting a bomb explode with a very long delay. Someone else will have to
> fix it, if there is problem. However, this may not be that important.
> The code is in good shape so that everyone else can fix it. The new
> hashed encoding is a lot simpler than the old one.

As said above. We'll have early adopter to cache potential bugs.

> The next release of Mercurial will have the non-hashed filename encoding
> in C. This not without risk.

But that does not introduce any incompatibility from 2.4 to 2.3.

-- 
Pierre-Yves David

http://www.logilab.fr/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20121002/d442233c/attachment.pgp>