The tests run clean with this.

Thank you for the help @pulkit . I have rebased it to the top.

In D5792#87320, @taapas1128 wrote:

@durin42 I have sent the patch for hg-stable repo (https://www.mercurial-scm.org/repo/hg-stable) . Maybe it is this the reason you are unable to apply the patch. Should I send a patch for hg repo ?

In D5960#87251, @durin42 wrote:

Huh. That's strictly a bug, as debugwaitonrepack should actually be waiting.

@durin42 I have sent the patch from hg-stable (https://www.mercurial-scm.org/repo/hg-stable) . Maybe it is this reason you are unable to apply the patch. Should I send a patch for hg repo ?

In D5801#87302, @martinvonz wrote:

In D5801#87300, @mharbison72 wrote:

In D5801#87296, @martinvonz wrote:

I noticed another bug and sent D5978. Maybe your test failure is because you're using the eol extension? I don't know what else would cause the \r in contrib.perf. I have no idea how that's related to this patch, though.

The \r is how output normally is on Windows. The test harness accounts for this when matching lines, but displays the actual output (with \r) when there are differences. The eol extension isn’t configured on this machine, but the custom HGRCPATH content from the test harness would override that anyway.

Ah, so the only difference is the extra "import newer module separately in try clause for early Mercurial" in contrib/perf.py then. This patch didn't change that file. Can you check again that it was this patch that caused that and that it's not just flaky?

In D5801#87300, @mharbison72 wrote:

In D5801#87296, @martinvonz wrote:

I noticed another bug and sent D5978. Maybe your test failure is because you're using the eol extension? I don't know what else would cause the \r in contrib.perf. I have no idea how that's related to this patch, though.

The \r is how output normally is on Windows. The test harness accounts for this when matching lines, but displays the actual output (with \r) when there are differences. The eol extension isn’t configured on this machine, but the custom HGRCPATH content from the test harness would override that anyway.

Anything recent. @ on https://mercurial-scm.org/hg is fine.

In D5801#87296, @martinvonz wrote:

I noticed another bug and sent D5978. Maybe your test failure is because you're using the eol extension? I don't know what else would cause the \r in contrib.perf. I have no idea how that's related to this patch, though.

@durin42 to which rev should I rebase it to ?

Patch still fails to apply. Would you please rebase it as requested?

In D5801#87273, @mharbison72 wrote:

For some reason, this breaks test-contrib-perf.t:

https://buildbot.mercurial-scm.org/builders/Win7%20x86_64%20hg%20tests/builds/1274/steps/run-tests.py%20%28python%202.7.13%29/logs/stdio

I also tried setting True and False in ui.relative-paths, to no effect. Any ideas?

In D5898#87275, @mharbison72 wrote:

This seems to have converted a test from dos to unix style. I'm not sure if that was intentional, or if this feature is still a WIP. (Sorry, I've been busy lately, and haven't had time to follow this closely)

https://buildbot.mercurial-scm.org/builders/Win7%20x86_64%20hg%20tests/builds/1274/steps/run-tests.py%20%28python%202.7.13%29/logs/stdio

This seems to have converted a test from dos to unix style. I'm not sure if that was intentional, or if this feature is still a WIP. (Sorry, I've been busy lately, and haven't had time to follow this closely)

For some reason, this breaks test-contrib-perf.t:

@durin42 I have made the change. Please review.

I like this, but can see it being vaguely controversial so I'll only give it a +1 here for now - if I don't see objections in a few days I'll go ahead and land it.

Huh. That's strictly a bug, as debugwaitonrepack should actually be waiting.

I'd fix this one style nit in flight (this actually looks good), but it no longer applies - could you rebase it for me?

In D5792#87115, @taapas1128 wrote:

@pulkit I have updated the description .