future of HgKit

[Andrey Somov]

Andrei Loskutov wrote:
> 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 ;-)
> 
I am sorry I do not like to be a dream-breaker...

- it is unclear whether Jython will ever be able to run Mercurial
- Jython runs at least a few times slower the CPython
- currently Mercurial is heavily using C modules to improve performance, 
since Jython has to stick to pure Python modules the performance 
degradation will be even worse
- talking to a socket will allow to overcome the license restriction but 
  anyway developers have to install Jython with Mercurial (Eclipse 
cannot include it as CVS or EGit)

I think using CPython through a socket may already improve the 
situation. Anyway this is the first (and the only) step we can do.