future of HgKit

[Greg Ward]

On Sat, Oct 3, 2009 at 2:39 PM, Andrey Somov <py4fun at gmail.com> wrote:
> Yes indeed, a read-only implementation can support basic continuous
> integration with Hudson (just to clone the source).
> But please keep in mind that for a successful build sometimes we need to
> change the source (Maven release plugin).

If you need to commit from Java code, what is wrong with

  String[] cmd = { "hg", "commit", "-m", message, ... };
  Runtime.exec(cmd);

?  Reads are faaaar more common than writes, so that is where you
should concentrate your optimization efforts.  And this *is* all about
optimization, right?  You can write a fairly complete wrapper for
Mercurial with java.lang.Runtime.exec(); MercurialEclipse proves this.
 It's not perfect, and it's not as elegant or as fast as it could be.
*But* *it* *works*.

> Mercurial is my favorite DVCS. Unfortunately I fail with each and every
> step I do to improve Mercurial-Java integration.

For some reason, talking about licensing issues brings out the worst
in free software communities.  So don't do it.  Stick to technical
stuff.  If you really want to license your code under a non-copyleft
license, you'd better make damn sure that it's not a "derived work" of
Mercurial.

Also, a couple of people (including me) have suggested that what you
need is Mercurial in a "slave daemon" mode.  I.e. your Java
application (say an IDE) just starts an hg daemon and controls it via
a socket.  That cuts out much of the performance impact of repeatedly
spawning 'hg' subprocesses.

Then write a Java library that knows all about
launching/finding/controlling an hg daemon.  I'm pretty sure that
could not be construed as a derived work, so you can license it
however you please.  (But really, please use a simple license like X11
or modified BSD.  Nobody complains about those licenses, since they
are compatible with everything.)

That still leaves the issue of evil Mercurial extensions that modify
the output format, or the 'defaults' config section that lets users do
same.  That's where you need to write a bit of Java code that replaces
an "hg branch" or "hg identify" call with "read a file or two in .hg".
 Heck, most of those little things will probably be easier to
reimplement in Java than deferring to the "real" hg.  It's the big
complicated stuff like "log" and "commit" where you don't want to
repeat what's already been written for you.

I really don't see this as a big difficult problem.  The "slave
daemon" mode is probably the hardest part to get right, since it means
designing a protocol.  But most of the protocol is already there in
the form of hg's command-line UI; you just have to turn that into
socket I/O rather than argv and stdout.  But the Java side of things
really should not be much code.  There is no need to port or rewrite
Mercurial in Java.

Greg