Nice work on this series. It's all queued now.

In D7116#104769, @Alphare wrote:

The following comparison shows that for input > 20 bytes, fnv has worse overall performance than xx

To reviewers: I only care about this patch (and its parent is needed for this to pass tests). Feel free to drop any other patches you don't like.

In D7135#104907, @martinvonz wrote:

In D7135#104894, @yuja wrote:

• a/tests/test-issue1175.t

+++ b/tests/test-issue1175.t
@@ -82,7 +82,6 @@

continue: hg graft --continue
$ hg graft --continue
grafting 1:5974126fad84 "b1"

• warning: can't find ancestor for 'b' copied from 'a'! $ hg log -f b -T 'changeset: {rev}:{node|short}\nsummary: {desc}\n\n' changeset: 3:376d30ccffc0 summary: b1

This test was added at a43fdf33a6be, which might need bad copy information.

Ah, so maybe the bug used to be incorrectly suppressed by the logic for finding the source in an old version. Thanks for digging that up. I somehow didn't think to check.

• a/mercurial/copies.py

+++ b/mercurial/copies.py
@@ -810,10 +810,11 @@

1. of the function is much faster (and is required for carrying copy
2. metadata across the rebase anyway). exclude = pathcopies(repo[fromrev], repo[skiprev])

+ pctx = wctx.p1()

for dst, src in pycompat.iteritems(pathcopies(repo[fromrev], repo[rev])):
    if dst in exclude:
        continue

• if dst in wctx:

+ if dst in wctx and dst not in pctx:

wctx[dst].markcopied(src)

Seems fine as we don't support hg rm b; hg cp a b case.

Yes, exactly. I should have mentioned that.

In D7135#104894, @yuja wrote:

• a/tests/test-issue1175.t

+++ b/tests/test-issue1175.t
@@ -82,7 +82,6 @@

continue: hg graft --continue
$ hg graft --continue
grafting 1:5974126fad84 "b1"

• warning: can't find ancestor for 'b' copied from 'a'! $ hg log -f b -T 'changeset: {rev}:{node|short}\nsummary: {desc}\n\n' changeset: 3:376d30ccffc0 summary: b1

This test was added at a43fdf33a6be, which might need bad copy information.

• a/tests/test-issue1175.t

+++ b/tests/test-issue1175.t
@@ -82,7 +82,6 @@

continue: hg graft --continue
$ hg graft --continue
grafting 1:5974126fad84 "b1"

• warning: can't find ancestor for 'b' copied from 'a'! $ hg log -f b -T 'changeset: {rev}:{node|short}\nsummary: {desc}\n\n' changeset: 3:376d30ccffc0 summary: b1

726bd0b612a2 does the same thing.

Wait, I found some problems, here is an amendment:

In D7000#103065, @khanchi97 wrote:

Sure :)

Fixed some os.environb and queued, thanks.

>> +++ b/mercurial/dirstate.py
>> @@ -919,6 +919,9 @@
>>
>>   matchalways = match.always()
>>   matchtdir = match.traversedir
>>   dmap = self._map
>>
>> +        if rustmod is not None:
>> +            dmap = self._map._rustmap
>
> If it's the same trick, can't it be abstracted away? `if rustmod` seems weird.
The main issue I faced is that Python classes built from `rust-cpython` cannot be subclassed, so we have to resort to an additional level of indirection. IIRC, the main reason was that there was no way of enforcing a subclass to call `super()` which would result in the Rust class not being initialized properly. Or maybe I'm missing the point?

In D7118#104834, @yuja wrote:

+++ b/mercurial/dirstate.py
@@ -919,6 +919,9 @@

matchalways = match.always()
matchtdir = match.traversedir
dmap = self._map

+ if rustmod is not None:
+ dmap = self._map._rustmap

If it's the same trick, can't it be abstracted away? if rustmod seems weird.

+++ b/mercurial/dirstate.py
@@ -919,6 +919,9 @@

matchalways = match.always()
matchtdir = match.traversedir
dmap = self._map

+ if rustmod is not None:
+ dmap = self._map._rustmap

TBH I'm not sure what's going on there. Perhaps a bad byte/newline sequence in the file?

In D7073#104561, @martinvonz wrote:

Should no longer be necessary with D7123, right?

In D7116#104685, @kevincox wrote:

I've seen very good results with https://github.com/servo/rust-fnv in the past so it is probably worth including that in the comparison and possibly using it. It is especially good for small keys which seems like a common case in hg.

Oops.

Since nobody seems to have plans to review this, I'll hold off on requesting review at this time.

I dropped this from committed because of discussion on this review and because Windows was not happy with the change: