Michael Hutchinson wrote:
On Wed, Nov 12, 2008 at 5:22 AM, Andreas Ericsson <ae@xxxxxx> wrote:
Recently, I've started learning C#. More for fun than anything else,
but one of the mono core devs sniffed me out and said they've been
thinking of porting jgit to C# to get a working IDE integration in
monodevelop. Currently, the only option available (with IDE
integration anyways) to the poor C# devs is either Microsoft's
crappy VSS, or the less crappy but still far from fantastic
Subversion.
I'm glad you're interested :-)
We do have an interface in MD for integrating VCS providers, and
although the only existing one is SVN, I believe some users are
working on bzr and perforce addins. I'd prefer to see git get
established as the default (D)VCS ...
Currently, to implement a VCS provider one needs to subclass
VersionControlSystem, as demonstrated by the SVN provider:
http://anonsvn.mono-project.com/viewvc/trunk/monodevelop/main/src/addins/VersionControl/MonoDevelop.VersionControl.Subversion/MonoDevelop.VersionControl.Subversion.addin.xml?view=markup.
We may need to extend the interfaces in order to expose more
DVCS-specific features, but I think it's best to find and fix these as
needed rather than speculatively implementing things.
I'll look into it. One thing I'd love to see is a "bisect" command
from within the IDE. That's one of those things that would make the
first IDE implementing it simply sell itself to hackers and suits
alike. Besides, "bisect", once learned, is such an awesome tool that
coders will start to adapt their workflow just to get full benefit
from it.
So in an effort to learn C#, I've decided to play along with this
(hopefully with some help from the MonoDevelop team), but it seems
to me that the best place to start is the fledgling libgit2 and link
that with git-sharp. The primary reason for this is ofcourse that I
think it'd be a terrible waste to have yet another from-scratch
implementation of git in a new language (ruby, java, C#, C...). The
secondary reason is that it would be neat to have more OSS projects
use my favourite scm.
That's actually one of the reasons we'd like a full managed
implementation --it'd be trivial to include to with cross-platform
Mono-based apps without worrying about architecture, C dependencies,
etc. For example, Tomboy could use git to store its notes, so users
would have a versioned history and better synch/merge. Then, for
example, you could build a Silverlight version that would have full
history in local storage.
What's considered "unmanaged"? (remember I'm a C# newbie here). Is it
stuff marked as "unsafe"? If so, there's a whole platoon of stuff to
re-implement, which is quite nuts. Iiuc, a "safe" way of implementing
unmanaged code is to always write to objects passed as parameters in
libgit2, like so:
int git_commit_get(git_commit *commit, git_oid *oid);
instead of
git_commit *git_commit_get(git_oid *oid);
as one can let git_commit be a class that gets instantiated and also
gc'd the normal way. libgit just has to make sure not to leak memory
and avoid side-effects, but that's good library design anyways, so
it's not as if C# integration would hurt libgit design.
I really think this would be a better approach that could make the C#
implementation stay on top of new features (such as the up-and-coming
v4 pack) a lot better than writing it from scratch.
libgit2 is intended to be portable to all unices as well as Windows
and Mac OS X, so there's no real problem there
Besides, getting something to rely on libgit2 early on is probably
the best way to get more people interested in making development of
it proceed rapidly.
Thoughts anyone?
I hadn't heard of libgit2 (it looks pretty recent)
It is.
but it looks
interesting -- at least stable APIs would no longer be a worry.
However, I think fully managed is the way to go, from the point of
view of much easier dependencies (on windows, mac, silverlight and
older linux distros) and licensing.
But who's going to write (and separately maintain) the 50k or so LoC
that will make up the git core lib in C#? It really is a waste of
resources, imo. Especially since libgit will get a lot of exercise,
whereas the C# code will get that of C#-based integrations only. I
have a feeling this would lead to bugs (or limitations) in the C#
implementation that the git community would be expected to deal with.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
