GNU bug report logs - #79235
31.0.50; Async checkin for Mercurial isn't async enough when checking in a patch

Previous Next

To reply to this bug, email your comments to 79235 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; Async checkin for Mercurial isn't async enough when
 checking in a patch
Date: Thu, 14 Aug 2025 13:15:18 +0100

X-debbugs-cc: dmitry <at> gutov.dev, sbaugh <at> janestreet.com, arne_bab <at> web.de, oub <at> mat.ucm.es

Hello,

vc-hg-checkin-patch runs two commands to effect committing the patch,
'hg import' to create the commit artefact, and 'hg update' to
fast-forward the working tree up to the new commit.
But currently when vc-async-checkin is non-nil, only the 'hg update'
command is run asynchronously.

This might be okay if the 'hg import' is always fast and 'hg update' can
be slow.  But I doubt that's the case in reality.  I would assume that
they could both be slow in certain repositories.

If we want to both commands asynchronously then we need to extend the
way async checkins are done to support multiple processes or write out a
tiny shell script to chain the two commands together.  I think I prefer
the latter.

But why are we using 'hg import --bypass' in the first place?  If we
didn't use --bypass then it would just be a single 'hg import' command,
I think, and that could easily be made asynchronous.

I looked at the thread from Dmitry was first working on this feature and
I couldn't see a definitive reason to by passing --bypass.
Dmitry, do you know why you did it in that way?

[1]  https://lists.gnu.org/archive/html/emacs-devel/2022-10/msg01533.html

-- 
Sean Whitton

Message #8 received at 79235 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Sean Whitton <spwhitton <at> spwhitton.name>, 79235 <at> debbugs.gnu.org
Cc: sbaugh <at> janestreet.com, arne_bab <at> web.de, oub <at> mat.ucm.es
Subject: Re: bug#79235: 31.0.50; Async checkin for Mercurial isn't async
 enough when checking in a patch
Date: Fri, 15 Aug 2025 01:23:40 +0300

Hi!

On 14/08/2025 15:15, Sean Whitton wrote:
> But why are we using 'hg import --bypass' in the first place?  If we
> didn't use --bypass then it would just be a single 'hg import' command,
> I think, and that could easily be made asynchronous.
> 
> I looked at the thread from Dmitry was first working on this feature and
> I couldn't see a definitive reason to by passing --bypass.
> Dmitry, do you know why you did it in that way?
> 
> [1]https://lists.gnu.org/archive/html/emacs-devel/2022-10/msg01533.html

The idea was to have the same behavior that we have with Git when using 
the checkin-patch feature: creating a commit on top of the tip without 
affecting the current directory tree.

So for example if you edited the 'vc-diff' buffer before checking it in, 
and the alterations intersect with the current changes in the working 
directory (current file, etc), there is no need to resolve any conflicts 
- they will just show up as differences when you call 'vc-diff' later.

And I'm not even sure you can 'hg import' without '--bypass' unless you 
stash all changes first - which means calling another hg command anyway 
(or doing it manually, which probably will be more work).

Message #11 received at 79235 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 79235 <at> debbugs.gnu.org, arne_bab <at> web.de, oub <at> mat.ucm.es,
 sbaugh <at> janestreet.com
Subject: Re: bug#79235: 31.0.50; Async checkin for Mercurial isn't async
 enough when checking in a patch
Date: Sat, 16 Aug 2025 13:04:20 +0100

Hello,

On Fri 15 Aug 2025 at 01:23am +03, Dmitry Gutov wrote:

> Hi!
>
> On 14/08/2025 15:15, Sean Whitton wrote:
>> But why are we using 'hg import --bypass' in the first place?  If we
>> didn't use --bypass then it would just be a single 'hg import' command,
>> I think, and that could easily be made asynchronous.
>> I looked at the thread from Dmitry was first working on this feature and
>> I couldn't see a definitive reason to by passing --bypass.
>> Dmitry, do you know why you did it in that way?
>> [1]https://lists.gnu.org/archive/html/emacs-devel/2022-10/msg01533.html
>
> The idea was to have the same behavior that we have with Git when using the
> checkin-patch feature: creating a commit on top of the tip without affecting
> the current directory tree.
>
> So for example if you edited the 'vc-diff' buffer before checking it in, and
> the alterations intersect with the current changes in the working directory
> (current file, etc), there is no need to resolve any conflicts - they will
> just show up as differences when you call 'vc-diff' later.
>
> And I'm not even sure you can 'hg import' without '--bypass' unless you stash
> all changes first - which means calling another hg command anyway (or doing it
> manually, which probably will be more work).

Thanks.  That's behaviour worth preserving.

How does the following plan seem to you:

- make the import command be the one that's done async, not the update

- leave a note saying if they are both potentially slow, we should do
  some messing about to make them both done asynchronously.  But don't
  do that yet in the absence of evidence.

-- 
Sean Whitton

Message #14 received at 79235 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 79235 <at> debbugs.gnu.org, arne_bab <at> web.de, oub <at> mat.ucm.es,
 sbaugh <at> janestreet.com
Subject: Re: bug#79235: 31.0.50; Async checkin for Mercurial isn't async
 enough when checking in a patch
Date: Sat, 16 Aug 2025 18:20:23 +0300

On 16/08/2025 15:04, Sean Whitton wrote:
> Thanks.  That's behaviour worth preserving.
> 
> How does the following plan seem to you:
> 
> - make the import command be the one that's done async, not the update
> 
> - leave a note saying if they are both potentially slow, we should do
>    some messing about to make them both done asynchronously.  But don't
>    do that yet in the absence of evidence.

Yep, sounds good to me.

So your measurements say that 'hg import' is often slower than the 
subsequent 'hg update'? Could be because of cold/warm disk cache, I suppose.

Message #17 received at 79235 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 79235 <at> debbugs.gnu.org, arne_bab <at> web.de, sbaugh <at> janestreet.com,
 oub <at> mat.ucm.es
Subject: Re: bug#79235: 31.0.50; Async checkin for Mercurial isn't async
 enough when checking in a patch
Date: Sat, 16 Aug 2025 19:43:50 +0100

Hello,

On Sat 16 Aug 2025 at 06:20pm +03, Dmitry Gutov wrote:

> On 16/08/2025 15:04, Sean Whitton wrote:
>> Thanks.  That's behaviour worth preserving.
>> How does the following plan seem to you:
>> - make the import command be the one that's done async, not the update
>> - leave a note saying if they are both potentially slow, we should do
>>    some messing about to make them both done asynchronously.  But don't
>>    do that yet in the absence of evidence.
>
> Yep, sounds good to me.
>
> So your measurements say that 'hg import' is often slower than the subsequent
> 'hg update'? Could be because of cold/warm disk cache, I suppose.

No measurements, I'm afraid.  It's just that when I implement
vc-async-checkin I didn't stop to consider which of the commands should
be asynchronous and just picked the one that runs later.

Actually stopping to think about it, creating a new commit object seems
likely to be more computationally intensive than moving the record of
where the tree is at.  This is fallible mostly because it's based on
understanding Git fairly well and assuming that Mercurial is just like
Git in this respect, which may or may not be true.

Thanks for the feedback, I'll work on it.

-- 
Sean Whitton

Message #22 received at 79235-done <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: 79235-done <at> debbugs.gnu.org
Subject: Now fixed
Date: Sun, 17 Aug 2025 11:38:08 +0100

Version: 31.1

Hello,

The refactoring is complete.

-- 
Sean Whitton

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.