[MonoDevelop] git integration with monodevelop

[Christian Hergert]

By unmanaged, he means the [DllImport] which you would need to do the call
to the extern in the shared library.

Everyone that has chimed in has considered doing the git code before,
believe us when we say we've thought about wrapping C.  In this case, it
will be far more flexible in C#.  Especially since tools like silverlight do
not allow DllImport's.

However, its your time, and I'd love to see git support happen any way
possible.

-- Christian

On Wed, Nov 12, 2008 at 11:55 PM, Andreas Ericsson <ae at op5.se> wrote:

> Michael Hutchinson wrote:
> > On Wed, Nov 12, 2008 at 5:22 AM, Andreas Ericsson <ae at op5.se> 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 at op5.se
> OP5 AB                             www.op5.se
> Tel: +46 8-230225                  Fax: +46 8-230231
> _______________________________________________
> Monodevelop-list mailing list
> Monodevelop-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monodevelop-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/monodevelop-list/attachments/20081113/fda82537/attachment.html