Skip to main content



      Home
Home » Eclipse Projects » EGit / JGit » Distributed Alternatives
Distributed Alternatives [message #1423] Tue, 14 April 2009 23:32 Go to next message
Eclipse UserFriend
Hallo,

good to see work happening around GIT, and I love the mentioning of adding
general infrastructure for (other) distributed SCM. After all Mercurial is
very hevyly used for Java (by Sun's endoresement). So I suggest to
evaluate architecture/features also with Hg in mind.

Greetings
Bernd
Re: Distributed Alternatives [message #3122 is a reply to message #1423] Wed, 15 April 2009 11:54 Go to previous messageGo to next message
Eclipse UserFriend
Bernd Eckenfels wrote:
>
> good to see work happening around GIT, and I love the mentioning of
> adding general infrastructure for (other) distributed SCM. After all
> Mercurial is very hevyly used for Java (by Sun's endoresement). So I
> suggest to evaluate architecture/features also with Hg in mind.

There already is a Mecurial team provider for Eclipse. But this group
and the proposed project are specifically to support a Git based team
provider.

However, we would like try to work with other DVCS team provider
developers, especially around the sync UI, as most DVCS implementations
provide similar levels of functionality and concepts, and code reuse
tends to be better than reinventing the wheel. :-)
Re: Distributed Alternatives [message #3154 is a reply to message #1423] Sat, 18 April 2009 10:48 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: alex_blewitt.yahoo.com

As you've already noted, this is specifically egit. However, a wider
discussion is available on bug 257706
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=257706). One of the things
I noted in my blog entry wrapping up EclipseCon was that one of the
inhibitors for the widespread adoption of SVN in Eclipse is due to the
fact the (xGPL) tools can't be distributed with Eclipse due to conflicting
with the EPL. So although the plugin might be under EPL, it has non-EPL
dependencies.

One of the strengths of EGit is that the library (JGit) is BSD which means
it can be redistributed from Eclipse.org. So whilst you're unlikely to see
an Eclipse release train with SVN or Hg support out-of-the-box, that might
not be the case for EGit.

In any case, the bug is the proper place to follow up on that aspect of
this discussion.

Alex
Re: Distributed Alternatives [message #499504 is a reply to message #3154] Mon, 23 November 2009 00:43 Go to previous messageGo to next message
Eclipse UserFriend
FYI: Now that svn moves to Apache I see a chance that svn migth become
part of the release train:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=294453

Alex Blewitt wrote:
> As you've already noted, this is specifically egit. However, a wider
> discussion is available on bug 257706
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=257706). One of the
> things I noted in my blog entry wrapping up EclipseCon was that one of
> the inhibitors for the widespread adoption of SVN in Eclipse is due to
> the fact the (xGPL) tools can't be distributed with Eclipse due to
> conflicting with the EPL. So although the plugin might be under EPL, it
> has non-EPL dependencies.
>
> One of the strengths of EGit is that the library (JGit) is BSD which
> means it can be redistributed from Eclipse.org. So whilst you're
> unlikely to see an Eclipse release train with SVN or Hg support
> out-of-the-box, that might not be the case for EGit.
>
> In any case, the bug is the proper place to follow up on that aspect of
> this discussion.
>
> Alex
>
Re: Distributed Alternatives [message #503703 is a reply to message #499504] Tue, 15 December 2009 07:12 Go to previous messageGo to next message
Eclipse UserFriend
Just wanted to give a short note about HgEclipse, a free open source Mercurial plugin for the Eclipse IDE:

http://javaforge.com/project/HGE

This project was originally cloned from the official MercurialEclipse project (started by Zingo Andersen), but HgEclipse 1.5.0 incorporates 300+ changes and important enhancements.

If you plan to coordinate your efforts with some other DVCS team provider project, then this one should not be overlooked either.
Re: Distributed Alternatives [message #570848 is a reply to message #1423] Wed, 15 April 2009 11:54 Go to previous messageGo to next message
Eclipse UserFriend
Bernd Eckenfels wrote:
>
> good to see work happening around GIT, and I love the mentioning of
> adding general infrastructure for (other) distributed SCM. After all
> Mercurial is very hevyly used for Java (by Sun's endoresement). So I
> suggest to evaluate architecture/features also with Hg in mind.

There already is a Mecurial team provider for Eclipse. But this group
and the proposed project are specifically to support a Git based team
provider.

However, we would like try to work with other DVCS team provider
developers, especially around the sync UI, as most DVCS implementations
provide similar levels of functionality and concepts, and code reuse
tends to be better than reinventing the wheel. :-)
Re: Distributed Alternatives [message #570887 is a reply to message #1423] Sat, 18 April 2009 10:48 Go to previous messageGo to next message
Eclipse UserFriend
As you've already noted, this is specifically egit. However, a wider
discussion is available on bug 257706
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=257706). One of the things
I noted in my blog entry wrapping up EclipseCon was that one of the
inhibitors for the widespread adoption of SVN in Eclipse is due to the
fact the (xGPL) tools can't be distributed with Eclipse due to conflicting
with the EPL. So although the plugin might be under EPL, it has non-EPL
dependencies.

One of the strengths of EGit is that the library (JGit) is BSD which means
it can be redistributed from Eclipse.org. So whilst you're unlikely to see
an Eclipse release train with SVN or Hg support out-of-the-box, that might
not be the case for EGit.

In any case, the bug is the proper place to follow up on that aspect of
this discussion.

Alex
Re: Distributed Alternatives [message #575744 is a reply to message #3154] Mon, 23 November 2009 00:43 Go to previous messageGo to next message
Eclipse UserFriend
FYI: Now that svn moves to Apache I see a chance that svn migth become
part of the release train:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=294453

Alex Blewitt wrote:
> As you've already noted, this is specifically egit. However, a wider
> discussion is available on bug 257706
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=257706). One of the
> things I noted in my blog entry wrapping up EclipseCon was that one of
> the inhibitors for the widespread adoption of SVN in Eclipse is due to
> the fact the (xGPL) tools can't be distributed with Eclipse due to
> conflicting with the EPL. So although the plugin might be under EPL, it
> has non-EPL dependencies.
>
> One of the strengths of EGit is that the library (JGit) is BSD which
> means it can be redistributed from Eclipse.org. So whilst you're
> unlikely to see an Eclipse release train with SVN or Hg support
> out-of-the-box, that might not be the case for EGit.
>
> In any case, the bug is the proper place to follow up on that aspect of
> this discussion.
>
> Alex
>
Re: Distributed Alternatives [message #576658 is a reply to message #499504] Tue, 15 December 2009 07:12 Go to previous message
Eclipse UserFriend
Just wanted to give a short note about HgEclipse, a free open source Mercurial plugin for the Eclipse IDE:

http://javaforge.com/project/HGE

This project was originally cloned from the official MercurialEclipse project (started by Zingo Andersen), but HgEclipse 1.5.0 incorporates 300+ changes and important enhancements.

If you plan to coordinate your efforts with some other DVCS team provider project, then this one should not be overlooked either.
Previous Topic:JGit not working correctly
Next Topic:Operation not supported - Internal Error
Goto Forum:
  


Current Time: Fri May 23 04:46:07 EDT 2025

Powered by FUDForum. Page generated in 0.06819 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top