Yes, I'd appreciate not adding any assumptions that nodes are 20 bytes.

In D7920#116596, @mharbison72 wrote:

I did hg phabread D7920 | hg import --bypass - on another Windows system, and it gives the following error when running the test (omitting the cascading failures):

The None return cases in node() match what the index_node()
C function does.

In D7920#116596, @mharbison72 wrote:

I did hg phabread D7920 | hg import --bypass - on another Windows system, and it gives the following error when running the test (omitting the cascading failures):

--- d:/mercurial/tests/test-phabricator.t
+++ d:/mercurial/tests/test-phabricator.t.err
@@ -56,7 +56,10 @@
   $ echo alpha > alpha
   $ hg ci --addremove -m 'create alpha for phabricator test Ç'
   adding alpha
-
+  transaction abort!
+  rollback completed
+  abort: decoding near 'ator test \x80': 'utf8' codec can't decode byte 0x80 in position 34: invalid start byte! (esc)
+  [255]
 A bad .arcconfig doesn't error out
   $ echo 'garbage' > .arcconfig
   $ hg config phabricator --debug
ERROR: test-phabricator.t output changed

So I'm not sure if there is a phabsend or phabread issue.

I did hg phabread D7920 | hg import --bypass - on another Windows system, and it gives the following error when running the test (omitting the cascading failures):

As stated yesterday, I'll have limited screen exposure time available for the next couple of day. I am going to ignore any minor nits during that time. (Am I happy to look at them afterward and follow up).

In D7894#116540, @martinvonz wrote:

In D7894#116407, @marmoute wrote:

In D7894#116397, @martinvonz wrote:

How much does this patch help performance?
I would also like to see performance numbers (even just rough ones) for the Rust version. Sorry about a possibly stupid question, but why will this on-disk nodemap be faster than building it from the index? Is it that the file is smaller and thus faster to read? Or is it more the building of the tree than the reading that's slow? You mentioned you use some private repo for testing this. How large is the 00changelog.n file in that repo and how large is 00changelog.i?

This save hundreds of milli second at initialization of large repositories. The repositories we are looking at are about 2 millions revisions. (but this will help smaller repository too). Mozilla try is a public repository in that range. It 00changelog.i is 103MB

And 00changelog.n?

I have no problem with the patch itself, but could you add a few words about the motivation? Even if that's just "no particular reason, I just like us to stay up to date".

In D7894#116407, @marmoute wrote:

In D7894#116397, @martinvonz wrote:

How much does this patch help performance?
I would also like to see performance numbers (even just rough ones) for the Rust version. Sorry about a possibly stupid question, but why will this on-disk nodemap be faster than building it from the index? Is it that the file is smaller and thus faster to read? Or is it more the building of the tree than the reading that's slow? You mentioned you use some private repo for testing this. How large is the 00changelog.n file in that repo and how large is 00changelog.i?

This save hundreds of milli second at initialization of large repositories. The repositories we are looking at are about 2 millions revisions. (but this will help smaller repository too). Mozilla try is a public repository in that range. It 00changelog.i is 103MB

In D7834#116533, @marmoute wrote:

Can you clarify which change you are actually requesting (I see mostly nits).
So far I see the **args → **opts change but I might be missing others.

Can you clarify which change you are actually requesting (I see mostly nits).

Amending the following in flight to make test-check-format.t (or black) happy:

Thank you, much appreciated.

There are a descent odds that their will be needed too.

There are descent odds that they will be needed too.

"." is just an aliast for p1(wdir(),

"." is just an alias for p1(wdir()),

Amending the perf numbers in commit message and fixed some spellings.

static PyObject *hashflags(line *l)
{

	char *s = l->start;

• size_t plen = pathlen(l);

+ Py_ssize_t plen = pathlen(l);

In D7894#116397, @martinvonz wrote:

How much does this patch help performance?
I would also like to see performance numbers (even just rough ones) for the Rust version. Sorry about a possibly stupid question, but why will this on-disk nodemap be faster than building it from the index? Is it that the file is smaller and thus faster to read? Or is it more the building of the tree than the reading that's slow? You mentioned you use some private repo for testing this. How large is the 00changelog.n file in that repo and how large is 00changelog.i?