Re: Core and Not-So Core

[Jon Seymour <jon.seymour@gmail.com>]

On 5/11/05, Noel Grandin <noel@peralex.com> wrote:
> Hi
> 
> Note that eclipse in particular has a fairly complicated repository
> provider interface.
> The subversion plugin developers (the subclipse project) took quite a
> while to implement their stuff.
> Basing your stuff off of their code would be a good idea.
> 

Noel,

Thanks for the info. I'll certainly have a look at what the subclipse
folks did as I am sure it will be helpful to understand the strategy. 
I do think we are in a slightly different situation here as we don't
quite have a stable library interface to git yet - Brad Roberts work
notwithstanding.

The repository API in pure Java is almost a no-brainer since Linus has
done such a good job in keeping the repository specification simple
and unambiguous.

A Java workspace API can take advantage of the abstraction and GUI
facilities that Java and Eclipse afford so will naturally be different
in form to the existing command line tools for manipulating the git
index. Certainly, there will be similarities - aspects of the 3-way
merge, for example, but there will be differences too - workspace
change detection will be somewhat assisted by the change notification
framework in Eclipse and won't require as much manual intervention.

> Also, they worked in 2 stages - in the first stage, they created
> something called the JavaHL interface, behind which they talked to the
> subversion C libraries using JNI.
> Then they created a pure-java implemenation of the subversion C
> libraries which also implemented the JavaHL interface, allowing them to
> compare and contrast the behaviour.
> 

At this stage, my thoughts are to implement a listener pattern to keep
the git index up to date, and I may well implement that by calling out
the the C git-update-cache executable. This can run in a background
thread so it needn't be a huge drag on interactive user performance.

Anyway, thanks for your input.

jon.