Mercurial socket interface

Greg Ward greg-hg at gerg.ca
Sun Oct 4 20:42:55 UTC 2009


> A socket interface wouldn't require any changes to core Hg, all the
> following would be do-able via an extension or simply an external script
> (I think):
> * new command "hg daemon" starts the socket interface (print port
> number, just print port number if an interface is already started for
> the repo?)

Or require the caller to specify how they want to address the daemon:
Unix socket, port number, whatever.  This would be fine for the
long-running IDE use case which has a captive hg daemon.

A more challenging use case is Ant or Maven, which are make-like:
short-lived command-line invocations.  An Ant process that needs to do
several hg operations (identify, pull, update, whatever) might benefit
from an hg daemon, but it seems like overkill to start one up for
every invocation of Ant.  In that case, it might be useful to have a
"find running daemon or start one for me" mode.  Which argues that "hg
daemon" does need to be able to report to its caller how to contact
the daemon.

> * new command "hg enddaemon" shuts down socket interface

Or "hg daemon --kill".

> The daemon would accept the hg CLI on its input channel (any regular hg
> command, simply split on spaces and call dispatch(args) unless inside

Ooh, no, not spaces!  Let's learn from the mistakes of make, shell,
find, and xargs: don't use a delimiter that can also occur in
filenames (or other command-line args).  Probably a better protocol
would be to transform

  hg command arg1 arg2 ... argN

to

  command\0arg1\0arg2\0...\0argN\n

Then there is no fancy quoting logic required.  Or you can avoid the
need for buffered I/O with an "even more binary" protocol:

  <nbytes>command\0arg1\0arg2\0...\0argN\0

where <nbytes> is (for example) a 16-bit unsigned int with the length
of the whole command string.  Read 2 bytes, parse, read <nbytes>
bytes.  Simple and no buffering required.

Disclaimer: I have never actually designed a network protocol, only
thought about it.  So I might be completely out to lunch here.  ;-)

Apart from those minor nits, this sounds totally sensible.  It's
pretty much the same lines I was thinking along.

Greg



More information about the Mercurial-devel mailing list