future of HgKit

[Theodore Tso]

On Sat, Oct 03, 2009 at 10:58:33PM +0200, Andrey Somov wrote:
> 
> with HUGE effort it is possible to rewrite let's say Mercurial 1.3. But 
> by the time it is finished Mercurial will be at version 1.7.

This is only a problem if Mercurial is contemplating protocol and/or
on-disk repository format changes.  Remember, the original
Python-based Mercurial needs to be backwards compatible with itself,
at least for a few releases.

> Rewrite will be always well behind the original. And it requires 
> considerable help form the python community (documentation).

That's the bigger problem (although people doing the re-implementation
can volunteer to provide the documentation, which the Python community
would be well advised to take --- documenting the on-disk format and
network protocol is a good thing!)  The issue though is Matt has
specifically said that he's against someone doing a re-implementation
under a non-GPL license, and would to some degree (whether its
actively or passively) work to make life difficult for someone doing a
re-implementation.

Personally, I think Matt is being overly paranoid.  If you believe
that the open source community can always do a better job faster, then
why worry about "competition" from a proprietary fork?  (Especially if
the proprietary fork is written in a performance-hostile langauge such
as Java?  :-) And if there is a large community of people using
Mercurial repositories which need to interoperate with the original
Python implementation, the likelihood that people will create
proprietary enhancements which are not compatible with the Mercurial
implementation is not very likely at all.

Still, Matt was the original designer and implementer of Hg, and so
his views should be given a certain amount of deference; even if it is
_legal_ to reimplement something which is format compatible with Hg
under a BSD license, that doesn't mean that it would be a friendly
thing to do.

And Java *does* have the equivalent of system(3) --- it's the
Runtime.exec methods of the Process Class.  So implementing an Eclipse
plugin using Runtime.exec seems like the first thing to try doing.

In the meantime, folks can keep an eye on JGit, and see if there are
proprietary companies trying to make proprietary enhancements to JGit
which lead to functionality that can't be duplicated in the core,
original version of Git.  I'll betcha it won't happen, and if it does,
very few people will use it because they will want to interoperate
with all of the Git users out there.  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, then maybe Matt and
the Mercurial community can re-evaluate their decision.  But really,
it's hard to believe, especially given how slow and bloated Eclipse
is, that the process startup time would be measurable --- I use an
Eclipse-based mail system, and it's _bad_; the only reason why I use
it is because my company forces me to use it.

						- Ted