unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: Andrii Kolomoiets <andreyk.mad@gmail.com>, emacs-devel@gnu.org
Subject: Re: VC hg backend that use mercurial command server.
Date: Mon, 15 Apr 2019 00:59:28 +0300	[thread overview]
Message-ID: <f5a79cc3-5c2a-54d0-9d05-f00e848d53d8@yandex.ru> (raw)
In-Reply-To: <206E26D8-9891-4171-875D-24904CC79878@gmail.com>

Hi Andrii,

On 13.04.2019 23:08, Andrii Kolomoiets wrote:

> I'm finally ready to present you VC hg backend that uses mercurial
> command server. It allows to communicate with single mercurial process
> over pipe rather than execute hg process for every command.
> 
> Also there is a possibility to answer to hg questions interactively.
> It's useful during merge when hg is in doubt about right action.
> 
> Besides that it has some changes and improvements described in
> commentary section of the package.

Thank you for this proposal.

> Hg process can be controlled via pipe (Linux, MacOS) or pty (TRAMP,
> Windows).
> 
> I think this package can make working with hg repositories more
> pleasant :)

I've tried it out briefly, but I hope others on this list who use 
Mercurial would share their impressions with us as well.

FWIW, my main brief impression is that it's prettier (which is a good 
thing, of course). The benefits of the approach alone didn't overcome 
the sluggishness of the monster that is the Mozilla repository (the only 
Hg repo I have).

> I want to contribute to improve built-in hg support.
> 
> May I ask which way it can be done better?
> 
> I see that all other backends are process based, so can this
> single-process backend be acceptable?

I don't think "process based" is a requirement, so on that front we're 
good. But speaking of conventions, like other backends, it will need a 
list of implemented/unimplemented backend commands in the commentary at 
the top.

> If so then is it better to replace
> hg backend (saving customizable options as much as possible) or provide
> two backends which share same options?

Generally speaking, we'd first add it as an option and then see about 
removing the older one.

But, again, I wonder what others think.

> Source code is here:
> https://github.com/muffinmad/emacs-vc-hgcmd/blob/master/vc-hgcmd.el
> 
> Hope you'll find it useful ;)

Thanks again.



  reply	other threads:[~2019-04-14 21:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-13 20:08 VC hg backend that use mercurial command server Andrii Kolomoiets
2019-04-14 21:59 ` Dmitry Gutov [this message]
2021-05-27 18:18   ` Xinglu Chen
2021-05-27 20:01     ` Andrii Kolomoiets
2021-05-28 15:49       ` Xinglu Chen
2021-05-28 20:41         ` Andrii Kolomoiets
2021-06-10 14:05         ` Andrii Kolomoiets

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f5a79cc3-5c2a-54d0-9d05-f00e848d53d8@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=andreyk.mad@gmail.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).