Proposing New HgKit API

[StefanC]

I propose we should create a high level HgKit? client-API (name stolen from SvnKit?).

If you check out the client API for SvnKit? there are a number of *Clients.

for instance

SVNCommitClient SVNDiffClient SVNLogClient etc.

I propose there should be a separate library for MEP which uses this library. the HgKit? would still use the hg binary and parse the output (until there is a real Java API for Hg :-)).

For instance, there could be a few hgclients right now such as

HgDiffClient?

• one stop shop for diffs

HgRemoteClient?

hg clone hg incoming hg outgoing

HgStatusClient?

HgCommitClient?

• commit
• add
• remove
• rollback

HgLogClient?

• well... logs! :-)

The benefit is, I believe, less complexity and you know where to go to look for a specific HgCommand? and where to implement it if its lacking.

I haven't thought too much of the overall structure of the client API, but if you or anyone else has some input...

[StefanC]

Proof of concept project

[StefanC]

I added a small proof of concept project.

check out the test/com.vectrace.hgkit.wc/HgStatusClientTest.java

Must change the setUp to point to correct hgExe.

In this hgkit I think I've added a fix for #157, if all commands were run using (future) HgKit? clients.

[StefanC]

Are there no opinions about this?

I've also been investigating some of the internals of hg, I believe that I can make a pure-java version of hg-status relativly easy, which would speed up the label-decorator even more.

the .hg/dirstate file contains a 40 byte heads and entries for each tracked file, big endian

1 byte - status ( (n)ormal, (a)dded, (r)emoved, (m)erged 3way)
4 bytes - filemode
4 bytes - filesize
4 byte - filemtime
4 byte - length
length bytes -  filepath (ordering may be wrong, writing out of my head)

http://www.selenic.com/mercurial/wiki/index.cgi/DirState

[zingo]

Hello Sorry I currently have a rather heavy daytime workload (e.g. evening and weekend work) and I didn't want to comment until I checked everthing. (and I still havn't) But it sounds like a nice ide, the code could be re-aranged something like this, actually I have started to implement all new hg-shell commands in the *.action folder with the intention to move all of them here.

What I don't know if it is needed is if it is needed to split the plugin into multiple plugins if possible I like it together if possible. ( Im not to subbirn about this so if the is a gain by splitting it then lets do it)

But before refactoring I think hg rename end hg move should be fixed.

Ill hope I can look into this in the next few days.

[StefanC]

A separate plugin was actually not really what I had in mind (that was just out of habit and for the proof of concept). The idea I had were to have a separate .jar file which knows nothing about eclipse or have any other dependency on anything but core java.

Then MEP could include this .jar in its runtime, the new .actions package is a good idea and would be a glue between hgkit and eclipse.

[Jerome Negre <jerome+hg@…>]

I've done something like this. HgCommand launches Hg and provides an API to set options and add files. It is used by various clients such as HgTagClientor HgCatClient that format the result.

HgCommand? is not meant to be subclassed nor used outside of its package, event if it is not marked final and is public. From a performance point-of-view, it is a bit faster than MercurialUtilities?.ExecuteCommand?* because no polling à la waitFor(Process process) is done.

Still missing: timeout configuration, and a way to ask the user if we should wait more before aborting a process.

[StefanC]

Maybe a separate hgkit library is overkill. I just downloaded and tried HgCommand?, replacing the call to ExecuteCommand? in HgOperation? with a

String[] args = getHgCommand();
HgCommand cmd = new HgCommand(args[1], getHgWorkingDir(), true).args(Arrays.copyOfRange(args, 2, args.length));
	        result = cmd.executeToString();

So integrating it in the small scale was easy, and I think we should probably use your HgCommand? instead of creating a new hgkit. And then deprecate ExecuteCommand?.

[zingo]

Ok I propose that this ticket is used for tracking the move to HgCommand? and the target release is 0.3.x (I plan to release a 0.2.x as soon as everything is stable) Is this OK?

[Christian Mahnke <cmahnke@…>]

I suppose this is the repository for hgkit: http://freehg.org/u/StefanC/hgkit/ I think this shoulde be postponed to version 0.4 (if planned) or even 1.0. Please check if hgkit can released under EPL, I suspect that there might be (licence) problems if it's released under GPL and incorporated in a release of MercurialEclipse?, which is EPL now.

[mohbana]

Good luck with this, looks interesting.