[PATCH 0 of 7 F2 series] fncache2 repo format

Adrian Buehlmann adrian at cadifra.com
Tue Oct 9 11:29:00 CDT 2012


On 2012-10-08 19:10, Bryan O'Sullivan wrote:
> On Sat, Oct 6, 2012 at 5:24 PM, Adrian Buehlmann <adrian at cadifra.com
> <mailto:adrian at cadifra.com>> wrote:
> 
>     I've used it to convert a Netbeans repo to the fncache2 format using
>     clone --pull.
>     It passes verify afterwards.
> 
> 
> I have a repo on which fncache2 gets some file name mangling cases
> wrong, making Mercurial unable to find some filelogs. I'm not yet sure
> what is going wrong, so I'm afraid I won't have any details to offer
> until I can make some more time to sort out what's up.

It might be interesting to know more about that. Did it fail on hg
verify? Can you do a "clone --pull" and then do a verify again?

I still can't figure out what could be wrong. Which perhaps doesn't mean
much. There's no proof that my fncache2 code is bug free.

I've now sent V3, which fixed a few things reported and rebased the
series on top of main tip.

I'd recommend you clone your repo again with V3.

> That being said, I've cooled considerably on the worth of
> fncache2. Having now dealt with the fncache2 code some, I have a feeling
> that the combination of new Python and C code is not in the end simpler
> than the new C fncache code. My current sense is that fncache2 will not
> be worth the churn of a new storage format.

I still find the terseness of the fncache2 code (C and Python code are
both very short) somewhat attractive, compared to the number of C code
lines in your C code for hashed paths. Reviewing this is a lot simpler
than hashmangle C function (where I stall each time I try to swallow it
and no one else has tried to have a look at so far).

The churn of a new storage format is certainly a major downside. It
wasn't that much of a problem in the past to have new formats though.
Apparently this has changed now.

> I'm going to spend a little time breaking the C fncache code into
> smaller pieces and adding a few comments to make them more easily
> reviewable.

That could be helpful. I think we might also need more testcases to
excercise as much code paths of the hashmangle function as we can.


More information about the Mercurial-devel mailing list