bug#63470: [PATCH] Use faster option for running vc-hg status

bug#63470: [PATCH] Use faster option for running vc-hg status

[Spencer Baugh]

[-- Attachment #1: Type: text/plain, Size: 446 bytes --]

Tags: patch




In GNU Emacs 29.0.90 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.15.12, Xaw scroll bars) of 2023-05-09 built on
 igm-qws-u22796a
Repository revision: 65c4a24aa0fc672bbf11e0c5187c6a29931b4363
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: CentOS Linux 7 (Core)

Configured using:
 'configure --with-x-toolkit=lucid --with-gif=ifavailable'


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Use-faster-option-for-running-vc-hg-status.patch --]
[-- Type: text/patch, Size: 1484 bytes --]

From 6fe0d4485b40f67473cad97f1b57c702dbeb3f57 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@janestreet.com>
Date: Fri, 12 May 2023 15:28:06 -0400
Subject: [PATCH] Use faster option for running vc-hg status

As the comment says, this causes us to depend on Mercurial 4.2, which
was released in 2017.  However, in modern Mercurial, removing the
"re:" "-I" "." options provides a 10x-20x speedup (because it allows
the Rust implementation of "hg status" to be used), so it's certainly
worth losing this compatibility.

* lisp/vc/vc-hg.el (vc-hg-dir-status-files):
Use --config status.relative=1 to make paths relative
---
 lisp/vc/vc-hg.el | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/lisp/vc/vc-hg.el b/lisp/vc/vc-hg.el
index 78231a0c954..2f6e5bc5e19 100644
--- a/lisp/vc/vc-hg.el
+++ b/lisp/vc/vc-hg.el
@@ -1381,11 +1381,9 @@ vc-hg-dir-status-files
   ;; XXX: We can't pass DIR directly to 'hg status' because that
   ;; returns all ignored files if FILES is non-nil (bug#22481).
   (let ((default-directory dir))
-    ;; TODO: Use "--config 'status.relative=1'" instead of "re:"
-    ;; when we're allowed to depend on Mercurial 4.2+
-    ;; (it's a bit faster).
     (vc-hg-command (current-buffer) 'async files
-                   "status" "re:" "-I" "."
+                   "--config" "status.relative=1"
+                   "status"
                    (concat "-mardu" (if files "i"))
                    "-C"))
   (vc-run-delayed
-- 
2.30.2

bug#63470: [PATCH] Use faster option for running vc-hg status

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Fri, 12 May 2023 15:28:43 -0400
> 
> As the comment says, this causes us to depend on Mercurial 4.2, which
> was released in 2017.  However, in modern Mercurial, removing the
> "re:" "-I" "." options provides a 10x-20x speedup (because it allows
> the Rust implementation of "hg status" to be used), so it's certainly
> worth losing this compatibility.

I don't understand: what will happen to users of Mercurial < 4.2?

And why cannot we detect the version and dispatch on that, instead of
doing this unconditionally?

bug#63470: [PATCH] Use faster option for running vc-hg status

[Spencer Baugh]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Date: Fri, 12 May 2023 15:28:43 -0400
>> 
>> As the comment says, this causes us to depend on Mercurial 4.2, which
>> was released in 2017.  However, in modern Mercurial, removing the
>> "re:" "-I" "." options provides a 10x-20x speedup (because it allows
>> the Rust implementation of "hg status" to be used), so it's certainly
>> worth losing this compatibility.
>
> I don't understand: what will happen to users of Mercurial < 4.2?

They will get an error message and the vc-dir buffer will fail to
update.

> And why cannot we detect the version and dispatch on that, instead of
> doing this unconditionally?

hg --version takes a quarter of a second on my machine, which itself
wipes out a lot of the performance benefit.  We could cache it, but it's
not clear to me how to do that correctly: there could be different hg
binaries in different directories, or over TRAMP, or other such things.

I could add a user option to revert to the old behavior, if you want.

(It would be nice if vc was available on ELPA, then maybe we could just
tell users of old mercurial versions to downgrade to an old version...)

bug#63470: [PATCH] Use faster option for running vc-hg status

[Dmitry Gutov]

On 12/05/2023 22:57, Spencer Baugh wrote:
>> And why cannot we detect the version and dispatch on that, instead of
>> doing this unconditionally?
> hg --version takes a quarter of a second on my machine, which itself
> wipes out a lot of the performance benefit.  We could cache it, but it's
> not clear to me how to do that correctly: there could be different hg
> binaries in different directories, or over TRAMP, or other such things.
> 
> I could add a user option to revert to the old behavior, if you want.

We could cache it like we do with vc-git--program-version. That's a 
simple memoization that doesn't take the host into account (though that 
could be implemented, too).

But it'd really make things easier if we're just allowed to rely on some 
new enough versions of Git and Hg.

> (It would be nice if vc was available on ELPA, then maybe we could just
> tell users of old mercurial versions to downgrade to an old version...)

I don't think so: "ELPA core" packages come from the master branch. 
Emacs 30 will come from it too. The only downgrade that will be 
available to the users of Emacs 30 is to revert to what they have 
bundled. And as soon as we make that change on master, that code will be 
gone.

bug#63470: [PATCH] Use faster option for running vc-hg status

[Eli Zaretskii]

> Date: Fri, 12 May 2023 23:10:05 +0300
> Cc: 63470@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 12/05/2023 22:57, Spencer Baugh wrote:
> > 
> > I could add a user option to revert to the old behavior, if you want.
> 
> We could cache it like we do with vc-git--program-version. That's a 
> simple memoization that doesn't take the host into account (though that 
> could be implemented, too).

Yes, that'd be a good-enough solution.

> But it'd really make things easier if we're just allowed to rely on some 
> new enough versions of Git and Hg.

It isn't easy to be backward-compatible, but we should strive at doing
that.

bug#63470: [PATCH] Use faster option for running vc-hg status

[Spencer Baugh]

[-- Attachment #1: Type: text/plain, Size: 756 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 12 May 2023 23:10:05 +0300
>> Cc: 63470@debbugs.gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>> 
>> On 12/05/2023 22:57, Spencer Baugh wrote:
>> > 
>> > I could add a user option to revert to the old behavior, if you want.
>> 
>> We could cache it like we do with vc-git--program-version. That's a 
>> simple memoization that doesn't take the host into account (though that 
>> could be implemented, too).
>
> Yes, that'd be a good-enough solution.
>
>> But it'd really make things easier if we're just allowed to rely on some 
>> new enough versions of Git and Hg.
>
> It isn't easy to be backward-compatible, but we should strive at doing
> that.

OK, revised backwards-compatible patch attached.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Use-faster-option-for-running-vc-hg-status-Bug-63470.patch --]
[-- Type: text/x-patch, Size: 2300 bytes --]

From 69d4a14dc37759ebc20196be00f0b1a6a139e6fd Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@janestreet.com>
Date: Fri, 12 May 2023 15:28:06 -0400
Subject: [PATCH] Use faster option for running vc-hg status (Bug#63470)

In modern Mercurial, removing the "re:" "-I" "." options provides a
10x-20x speedup because it allows the Rust implementation of "hg
status" to be used.

* lisp/vc/vc-hg.el (vc-hg--program-version): Add.
(vc-hg-dir-status-files): Use --config status.relative=1 to make paths
relative when available.
---
 lisp/vc/vc-hg.el | 25 ++++++++++++++++++-------
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/lisp/vc/vc-hg.el b/lisp/vc/vc-hg.el
index 78231a0c954..bc7787d8c6c 100644
--- a/lisp/vc/vc-hg.el
+++ b/lisp/vc/vc-hg.el
@@ -1377,17 +1377,28 @@ vc-hg-after-dir-status
 ;; Follows vc-exec-after.
 (declare-function vc-set-async-update "vc-dispatcher" (process-buffer))
 
+(defvar vc-hg--program-version nil)
+
+(defun vc-hg--program-version ()
+  (or vc-hg--program-version
+      (setq vc-hg--program-version
+            (with-temp-buffer
+              (condition-case _ (vc-hg-command t 0 nil "version")
+                (error "0")
+                (:success
+                 (goto-char (point-min))
+                 (re-search-forward "Mercurial Distributed SCM (version \\([0-9][0-9.]+\\)")
+                 (string-trim-right (match-string 1) "\\.")))))))
+
 (defun vc-hg-dir-status-files (dir files update-function)
   ;; XXX: We can't pass DIR directly to 'hg status' because that
   ;; returns all ignored files if FILES is non-nil (bug#22481).
   (let ((default-directory dir))
-    ;; TODO: Use "--config 'status.relative=1'" instead of "re:"
-    ;; when we're allowed to depend on Mercurial 4.2+
-    ;; (it's a bit faster).
-    (vc-hg-command (current-buffer) 'async files
-                   "status" "re:" "-I" "."
-                   (concat "-mardu" (if files "i"))
-                   "-C"))
+    (apply #'vc-hg-command (current-buffer) 'async files
+           "status" (concat "-mardu" (if files "i")) "-C"
+           (if (version<= "4.2" (vc-hg--program-version))
+               '("--config" "status.relative=1")
+             '("re:" "-I" "."))))
   (vc-run-delayed
     (vc-hg-after-dir-status update-function)))
 
-- 
2.30.2

bug#63470: [PATCH] Use faster option for running vc-hg status

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Cc: Dmitry Gutov <dmitry@gutov.dev>,  63470@debbugs.gnu.org
> Date: Tue, 16 May 2023 16:39:49 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Date: Fri, 12 May 2023 23:10:05 +0300
> >> Cc: 63470@debbugs.gnu.org
> >> From: Dmitry Gutov <dmitry@gutov.dev>
> >> 
> >> On 12/05/2023 22:57, Spencer Baugh wrote:
> >> > 
> >> > I could add a user option to revert to the old behavior, if you want.
> >> 
> >> We could cache it like we do with vc-git--program-version. That's a 
> >> simple memoization that doesn't take the host into account (though that 
> >> could be implemented, too).
> >
> > Yes, that'd be a good-enough solution.
> >
> >> But it'd really make things easier if we're just allowed to rely on some 
> >> new enough versions of Git and Hg.
> >
> > It isn't easy to be backward-compatible, but we should strive at doing
> > that.
> 
> OK, revised backwards-compatible patch attached.

Thanks, but I'd prefer to call the new function only once, and record
the result in some variable.  We do such things in umpteen other
places, so it looks strange to test the version each time only in this
case.

If you are afraid that somehow the version could change while the
Emacs session runs, we could add a command to recompute the version.
I think it's reasonable to ask the user to do this by hand, since
installing a new version of Mercurial should be something users are
aware of.

bug#63470: [PATCH] Use faster option for running vc-hg status

[Spencer Baugh]

[-- Attachment #1: Type: text/plain, Size: 1893 bytes --]

On Wed, May 17, 2023, 07:39 Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Spencer Baugh <sbaugh@janestreet.com>
> > Cc: Dmitry Gutov <dmitry@gutov.dev>,  63470@debbugs.gnu.org
> > Date: Tue, 16 May 2023 16:39:49 -0400
> >
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> > >> Date: Fri, 12 May 2023 23:10:05 +0300
> > >> Cc: 63470@debbugs.gnu.org
> > >> From: Dmitry Gutov <dmitry@gutov.dev>
> > >>
> > >> On 12/05/2023 22:57, Spencer Baugh wrote:
> > >> >
> > >> > I could add a user option to revert to the old behavior, if you
> want.
> > >>
> > >> We could cache it like we do with vc-git--program-version. That's a
> > >> simple memoization that doesn't take the host into account (though
> that
> > >> could be implemented, too).
> > >
> > > Yes, that'd be a good-enough solution.
> > >
> > >> But it'd really make things easier if we're just allowed to rely on
> some
> > >> new enough versions of Git and Hg.
> > >
> > > It isn't easy to be backward-compatible, but we should strive at doing
> > > that.
> >
> > OK, revised backwards-compatible patch attached.
>
> Thanks, but I'd prefer to call the new function only once, and record
> the result in some variable.  We do such things in umpteen other
> places, so it looks strange to test the version each time only in this
> case.
>

Isn't that what I'm doing? I record the version in a variable and only
compute it once.

Also, the way I'm doing it exactly matches how vc-git does it.

Do you mean a variable that controls whether to use the new argument
method? Should the result be computed at load time or at first use of the
variable?

>
> If you are afraid that somehow the version could change while the
> Emacs session runs, we could add a command to recompute the version.
> I think it's reasonable to ask the user to do this by hand, since
> installing a new version of Mercurial should be something users are
> aware of.
>

[-- Attachment #2: Type: text/html, Size: 3266 bytes --]

bug#63470: [PATCH] Use faster option for running vc-hg status

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Wed, 17 May 2023 07:47:09 -0400
> Cc: Dmitry Gutov <dmitry@gutov.dev>, 63470@debbugs.gnu.org
> 
>  Thanks, but I'd prefer to call the new function only once, and record
>  the result in some variable.  We do such things in umpteen other
>  places, so it looks strange to test the version each time only in this
>  case.
> 
> Isn't that what I'm doing? I record the version in a variable and only compute it once.

Sorry, you are right.  I claim temporary blindness.

bug#63470: [PATCH] Use faster option for running vc-hg status

[Spencer Baugh]

[-- Attachment #1: Type: text/plain, Size: 301 bytes --]


A fix to the patch: passing the correct configuration key as an
argument.  The old version did nothing... but fortunately it was setting
the configuration key to its default value, so it happened to work.
I've tested now that it works even when commands.status.relative=0 is
set by the user's hgrc.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Use-faster-option-for-running-vc-hg-status-Bug-63470.patch --]
[-- Type: text/x-patch, Size: 2318 bytes --]

From ff6163fac51759945aa619ca6bf28413be4a53e0 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@janestreet.com>
Date: Fri, 12 May 2023 15:28:06 -0400
Subject: [PATCH] Use faster option for running vc-hg status (Bug#63470)

In modern Mercurial, removing the "re:" "-I" "." options provides a
10x-20x speedup because it allows the Rust implementation of "hg
status" to be used.

* lisp/vc/vc-hg.el (vc-hg--program-version): Add.
(vc-hg-dir-status-files): Use --config commands.status.relative=1 to
make paths relative when available.
---
 lisp/vc/vc-hg.el | 25 ++++++++++++++++++-------
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/lisp/vc/vc-hg.el b/lisp/vc/vc-hg.el
index 78231a0c954..688fb6e0252 100644
--- a/lisp/vc/vc-hg.el
+++ b/lisp/vc/vc-hg.el
@@ -1377,17 +1377,28 @@ vc-hg-after-dir-status
 ;; Follows vc-exec-after.
 (declare-function vc-set-async-update "vc-dispatcher" (process-buffer))
 
+(defvar vc-hg--program-version nil)
+
+(defun vc-hg--program-version ()
+  (or vc-hg--program-version
+      (setq vc-hg--program-version
+            (with-temp-buffer
+              (condition-case _ (vc-hg-command t 0 nil "version")
+                (error "0")
+                (:success
+                 (goto-char (point-min))
+                 (re-search-forward "Mercurial Distributed SCM (version \\([0-9][0-9.]+\\)")
+                 (string-trim-right (match-string 1) "\\.")))))))
+
 (defun vc-hg-dir-status-files (dir files update-function)
   ;; XXX: We can't pass DIR directly to 'hg status' because that
   ;; returns all ignored files if FILES is non-nil (bug#22481).
   (let ((default-directory dir))
-    ;; TODO: Use "--config 'status.relative=1'" instead of "re:"
-    ;; when we're allowed to depend on Mercurial 4.2+
-    ;; (it's a bit faster).
-    (vc-hg-command (current-buffer) 'async files
-                   "status" "re:" "-I" "."
-                   (concat "-mardu" (if files "i"))
-                   "-C"))
+    (apply #'vc-hg-command (current-buffer) 'async files
+           "status" (concat "-mardu" (if files "i")) "-C"
+           (if (version<= "4.2" (vc-hg--program-version))
+               '("--config" "commands.status.relative=1")
+             '("re:" "-I" "."))))
   (vc-run-delayed
     (vc-hg-after-dir-status update-function)))
 
-- 
2.30.2

bug#63470: [PATCH] Use faster option for running vc-hg status

[Dmitry Gutov]

Version: 30.1

On 22/05/2023 20:58, Spencer Baugh wrote:
> A fix to the patch: passing the correct configuration key as an
> argument.  The old version did nothing... but fortunately it was setting
> the configuration key to its default value, so it happened to work.
> I've tested now that it works even when commands.status.relative=0 is
> set by the user's hgrc.

Thanks! Installed.

Am I right to understand, BTW, that the supposed 10x speedup will only 
materialize with a very new Mercurial?

With Hg 6.2.2 I see a small improvement here, but it's more like 10% 
bump than a 1000% one.

bug#63470: [PATCH] Use faster option for running vc-hg status

[Dmitry Gutov]

On 16/05/2023 23:39, Spencer Baugh wrote:
> Eli Zaretskii<eliz@gnu.org>  writes:
> 
>>> Date: Fri, 12 May 2023 23:10:05 +0300
>>> Cc:63470@debbugs.gnu.org
>>> From: Dmitry Gutov<dmitry@gutov.dev>
>>>
>>> On 12/05/2023 22:57, Spencer Baugh wrote:
>>>> I could add a user option to revert to the old behavior, if you want.
>>> We could cache it like we do with vc-git--program-version. That's a
>>> simple memoization that doesn't take the host into account (though that
>>> could be implemented, too).
>> Yes, that'd be a good-enough solution.
>>
>>> But it'd really make things easier if we're just allowed to rely on some
>>> new enough versions of Git and Hg.
>> It isn't easy to be backward-compatible, but we should strive at doing
>> that.
> OK, revised backwards-compatible patch attached.
> 

Thanks! It does look better, performance-wise.

Would you say that the performance of project--vc-list-files could be 
similarly improved for Hg? Or does the Rust implementation in question 
already get used for 'hg status .', as long as there is no "re:" involved?

bug#63470: [PATCH] Use faster option for running vc-hg status

[Spencer Baugh]

Dmitry Gutov <dmitry@gutov.dev> writes:
> On 16/05/2023 23:39, Spencer Baugh wrote:
>> Eli Zaretskii<eliz@gnu.org>  writes:
>> 
>>>> Date: Fri, 12 May 2023 23:10:05 +0300
>>>> Cc:63470@debbugs.gnu.org
>>>> From: Dmitry Gutov<dmitry@gutov.dev>
>>>>
>>>> On 12/05/2023 22:57, Spencer Baugh wrote:
>>>>> I could add a user option to revert to the old behavior, if you want.
>>>> We could cache it like we do with vc-git--program-version. That's a
>>>> simple memoization that doesn't take the host into account (though that
>>>> could be implemented, too).
>>> Yes, that'd be a good-enough solution.
>>>
>>>> But it'd really make things easier if we're just allowed to rely on some
>>>> new enough versions of Git and Hg.
>>> It isn't easy to be backward-compatible, but we should strive at doing
>>> that.
>> OK, revised backwards-compatible patch attached.
>> 
>
> Thanks! It does look better, performance-wise.
>
> Would you say that the performance of project--vc-list-files could be
> similarly improved for Hg? Or does the Rust implementation in question
> already get used for 'hg status .', as long as there is no "re:"
> involved?

As of very recently in Mercurial trunk, yes, the Rust implementation
will be used for project--vc-list-files.  (It only just got support for
-0)

Although note: currently the Rust implementation doesn't support "hg
status somefile"; that will fall back to the Python implementation.  So
"hg status ." would be slow, actually, but "hg status" (as
project--vc-list-files inexplicably seems to do, despite passing "." for
file-or-list, based on inspecting with (vc-edit-next-command)) is fast.

(either way though, I'm working on making "hg status somefile" work in
Rust, since that will make vc-hg-state fast)

bug#63470: [PATCH] Use faster option for running vc-hg status

[Dmitry Gutov]

On 19/05/2023 17:34, Spencer Baugh wrote:
>> Thanks! It does look better, performance-wise.
>>
>> Would you say that the performance of project--vc-list-files could be
>> similarly improved for Hg? Or does the Rust implementation in question
>> already get used for 'hg status .', as long as there is no "re:"
>> involved?
> As of very recently in Mercurial trunk, yes, the Rust implementation
> will be used for project--vc-list-files.  (It only just got support for
> -0)
> 
> Although note: currently the Rust implementation doesn't support "hg
> status somefile"; that will fall back to the Python implementation.  So
> "hg status ." would be slow, actually, but "hg status" (as
> project--vc-list-files inexplicably seems to do, despite passing "." for
> file-or-list, based on inspecting with (vc-edit-next-command)) is fast.
> 
> (either way though, I'm working on making "hg status somefile" work in
> Rust, since that will make vc-hg-state fast)

Nice! Thank you.

bug#63470: [PATCH] Use faster option for running vc-hg status

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Cc: 63470@debbugs.gnu.org
> Date: Fri, 12 May 2023 15:57:41 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > I don't understand: what will happen to users of Mercurial < 4.2?
> 
> They will get an error message and the vc-dir buffer will fail to
> update.

That's unacceptable, sorry.  There are better solutions than just stop
supporting those users, so this is too harsh.

> > And why cannot we detect the version and dispatch on that, instead of
> > doing this unconditionally?
> 
> hg --version takes a quarter of a second on my machine, which itself
> wipes out a lot of the performance benefit.  We could cache it, but it's
> not clear to me how to do that correctly: there could be different hg
> binaries in different directories, or over TRAMP, or other such things.

There's no reason to assume there's more than one Mercurial
installation on PATH.  We could allow reinitialization of the version,
but that would be holier that Pope, IMO.  We don't do that with Git,
AFAIR.

> I could add a user option to revert to the old behavior, if you want.

The result of the version test could set the value of the defacustom,
but if we add such a defcustom, its default value should be to probe
the system, not to assume version 4.2 or later.

> (It would be nice if vc was available on ELPA, then maybe we could just
> tell users of old mercurial versions to downgrade to an old version...)

Does package.el support downgrading of packages, let alone of built-in
packages?

bug#63470: [PATCH] Use faster option for running vc-hg status

[Dmitry Gutov]

On 12/05/2023 22:43, Eli Zaretskii wrote:
>> From: Spencer Baugh<sbaugh@janestreet.com>
>> Date: Fri, 12 May 2023 15:28:43 -0400
>>
>> As the comment says, this causes us to depend on Mercurial 4.2, which
>> was released in 2017.  However, in modern Mercurial, removing the
>> "re:" "-I" "." options provides a 10x-20x speedup (because it allows
>> the Rust implementation of "hg status" to be used), so it's certainly
>> worth losing this compatibility.
> I don't understand: what will happen to users of Mercurial < 4.2?

How much longer do we need to support CentOS 7?

Anything newer has Mercurial 4.8+. And Mercurial's latest is 6.4.3.

bug#63470: [PATCH] Use faster option for running vc-hg status

[Eli Zaretskii]

> Date: Fri, 12 May 2023 23:06:06 +0300
> Cc: 63470@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 12/05/2023 22:43, Eli Zaretskii wrote:
> >> From: Spencer Baugh<sbaugh@janestreet.com>
> >> Date: Fri, 12 May 2023 15:28:43 -0400
> >>
> >> As the comment says, this causes us to depend on Mercurial 4.2, which
> >> was released in 2017.  However, in modern Mercurial, removing the
> >> "re:" "-I" "." options provides a 10x-20x speedup (because it allows
> >> the Rust implementation of "hg status" to be used), so it's certainly
> >> worth losing this compatibility.
> > I don't understand: what will happen to users of Mercurial < 4.2?
> 
> How much longer do we need to support CentOS 7?

As long as it's feasible, i.e. doesn't cause us to jump through too
many hoops.