future of HgKit

[Andrei Loskutov]

On Sun, 04 Oct 2009 19:00:05 +0200, <mercurial-request at selenic.com> wrote:

> it's hard to believe, especially given how slow and bloated Eclipse
> is, that the process startup time would be measurable

It is, unfortunately.
MercurialEclipse starts hg processes to integrate Eclipse with hg, and it  
IS slow in some cases where you have to run hg *many* times.

Beside this, I have many issues with hg-to-IDE integration, and most of  
them are mostly because I have to install a right hg binaries version  
which matches both my current OS version and Eclipse plugin version, and  
this is not so easy...

> If the experiment turns out to
> be positive for JGit, and indeed people find that a native
> implementation in Java really is that much better

It IS better, at least for EGit. I think Git/JGit/EGit) will be in a short  
time much more interesting for Java developers then hg/MercurialEclipse,  
because it comes bundled with Eclipse and will run on ALL platforms  
without any extra binaries. I guess it will be the standard Eclipse VCS in  
the future.

Unfortunately, this is not true for hg/MercurialEclipse.

I can't run hg on Linux in the office, because I can't install new python  
version because I have no root rights and it is not allowed to change the  
developing environment in general (where a specific python version is a  
constraint).
Same for Windows; the latest builds of hg are bundled with TortoiseHG, but  
I don't like to install this very invasive program on my machine, so I  
have to build hg from source (which I don't like to) or to wait until  
somebody releases the updated hg Windows binaries.
Additionally, I can't fix a simplest bug in hg simply because I have no  
time to learn another one language for the sake of bug fixing.

> if a daemon mode is developed for mercurial,
> running it under jython becomes a valid
> alternative.
> the jython performace problems come from
> the startup of the interpreter.
> and with jython you can commmit too.

I think this would be the best option ever.
Make sure Jython can run "native" hg python code with no issues and  
provide a Java API on top of that.
Then start a "deamon" Jython/hg thread in the same VM as Eclipse and use  
plain Java API to access hg data.
No erroneous hg status caches, no parsing of specific output/error  
messages from the command line, a "native" Java Changeset class... Sounds  
like a dream ;-)

-- 
Kind regards,
Mit freundlichen Grüßen
Andrei Loskutov

@Home: http://andrei.gmxhome.de/