Which has better Eclipse support: git or Mercurial

views:

10661

answers:

+39 Q:

Which has better Eclipse support: git or Mercurial

I work in a team of Java-developers who are very familiar with Eclipse. Most of the team uses Windows. We are switching our main project from CVS into something newer. Subversion seems already old and not really that much better than CVS. We are really interested in distributed version control systems, mainly Mercurial and git. Which of them has better plugin support for Eclipse?

Or is it so, that we should switch to NetBeans and choose Mercurial to have proper support in the IDE? I'm afraid that if we face a switch to NetBeans people might feel that maybe we should just stick to Subversion instead. That would be depressing.

+4 A:

This wasn't the point of your question, but you should be aware that Windows is a decidedly second-class citizen in the world of git.

To address the question you asked, the Eclipse plugin for git is probably positioned better for the future, since it recently became an official Eclipse Technology Project. The hg plugin doesn't seem to be headed for such a tight relationship.

Hank Gay 2009-08-12 18:47:00

Yes, that's why I mentioned Windows also in the question. Some people seem to think that even though it uses cygwin or other means to emulate the unix shell it's still working fine with windows.

auramo 2009-08-12 18:48:55

I've heard things work well if you are willing to use cygwin or the like, but that you're unlikely to get any sympathy if you have questions for the mailing list, etc.

Hank Gay 2009-08-12 18:51:03

+2 A:

As Hank already said git is better positioned for the future since we now have EGit (http://www.eclipse.org/egit/). Since they are using their own git implementation (JGit - http://www.jgit.org/) which is all Java, Windows is not a real problem anymore I guess.

seb 2009-08-12 18:54:59

Thanks! JGit sounds comforting from Windows point of view.

auramo 2009-08-12 18:56:55

Yeah, it will be - but it's still a work in progress and there are some features which are not yet supported by egit/jgit. There is also no command line for JGit that I'm aware of to replicate the Git command line - but I see no technical reason why that may not be the case in the future.Cygwin tends to work, but there's an issue with Windows wanting to make everything executable, even for text files.

AlBlue 2009-08-12 19:03:23

Does JGit really need a command line? If I have to drop to CLI (not every day), I quess it would be possible/tolerable to use the cygwin git version?

auramo 2009-08-12 19:06:18

The format of the repo is identical for JGit and (c)git. So you can use either/both. It's much better than CVS where local timestamps etc. can be different. But you probably need a command-line app at the moment, which will be (c)git

AlBlue 2009-08-12 20:36:39

+2 A:

Subversion is quite a bit better than CVS and serves a different environment that git/mercurial. Everything depends on your network setup and preferred method of development.

If everyone is network connected and development isn't very "brancy", then Subversion may be a good choice. If development is branchy, git/mercurial is a better choice.

If everyone is not on the same network or develop in many different locations, git/mercurial is a very good choice.

In either case, make sure everyone is comfortable with merging.

As far as IDE integration...

I have tried Eclipse plugins for subversion and mercurial. Both worked well enough, but ultimately the command line is faster and has more power ultimately allowing developers to pick their own IDE.

My suggestions:

Which ever tool you pick, learn the command line. You'll be happy when the plugin breaks or can't do something.
Make sure everyone understands how each system works
1. subversion - global revision, branches/tags/trunk
2. mercurial/git - local commits, everyone is a branch, merging/push/pull, convention of a central repository vs. configuration

basszero 2009-08-12 18:57:08

We have been spoiled with the excellent CVS plugin Eclipse provides. Even if CVS in itself is a relic, the plugin has always been rock solid and the synchronize view has worked so well, that the situations where we have had to drop to command line have been very rare. Also, since we are talking about people of whom most use windows, command line isn't as natural part of everyday life as it is for *nix developers.

auramo 2009-08-12 19:01:47

+10 A:

There's a temporal aspect to your question, which isn't covered here. That is, which has better support now. That's quite distinct from which has better support in the future, or is likely to have.

The eGit project is, at the moment, still in development. It is possible to use for some things, but it's not self-hosting at the moment (in that it's still necessary to drop into the command line in order to make it happen). I have no such knowledge of the state of the Hg plugin.

However, Hg is licensed under the GPL and as such, won't be made part of an official Eclipse download ever. It doesn't matter how good (or bad) it is - the licensing prevents it from being used as part of an Eclipse.org download. And after all, one of the biggest problems that Eclipse has had with SVN for a while is the lack of a standard, out-of-the-box-it-just-works approach. That's why there's two competing processes, and even though one is an Eclipse.org project, it requires downloads from outside Eclipse in order to actually work.

At this point, the future of Eclipse and DVCS lies with eGit, whether it's good or not. It is quite likely that the Eclipse 3.6 series will have eGit support by default; and it's based on the same JGit library that NetBeans will use for the NetBeans implementation, so at least it's likely to be kept up to date.

There was a long debate about the merits of different DVCSs on Eclipse bug 257706 and the net result was for Git as the future DVCS for Eclipse, rather than other DVCSs. I wrote some other thoughts from EclipseCon at the time.

Disclaimer: I'm a contributor to eGit. I may well be biased, but I'm trying to report on the state of play of how likely it is for future releases of Eclipse to have DVCS support, rather than any statement of the current support for either.

AlBlue 2009-08-12 19:01:08

So in 300+ words you just said "The answer to your question isn't git, but I wish it was and am trying to make that true someday".

Ry4an 2009-08-12 22:14:27

MercurialEclipse works. Now. The eclipse bug cited above agrees that it works better now than the git plugin. The licensing issue is somewhat questionable: both mercurial and git are GPL. You can use them through the command line (as MercurialEclipse does) or _reimplement_ the entire tool from scratch (eGit's choice). It's not clear that this is a sustainable approach as the tool it mirrors evolves, but if I were going to attempt it I'd do it with Mercurial, which has a simpler, smaller, more consistent interface.

brendan 2009-08-15 02:11:52

The point with the licensing is that whilst the command line (c)git tool is GPL, the eGit implementation is EPL (and the JGit on which it sits is BSD). It's worth noting that the way all Git code works is by operating on the Git repository as a file system, and the core (which is already implemented in JGit) is the basis (plubming) upon which all Git command line tools (porcelain) are based. So JGit/eGit are just another porcelain in Git terms.If there were a fully Java based Hg plugin that was EPL then I'm sure that would have an impact, but there isn't one that has no (L)GPL dependencies.

AlBlue 2009-08-15 09:05:25

FYI both EGit and JGit have now been approved to transition to Eclipse.org as the upstream location for any Java-based Git plugins (which would benefit NetBeans, since JGit is still available under a BSD license). It therefore makes it quite likely that an early release of EGit will be available in the near future in 3.6 milestone builds, as well as being available for download for older Eclipse installs.

AlBlue 2009-09-22 17:08:45

+20 A:

Subversion seems already old and not really that much better than CVS.

Whoa there! SVN is decidedly better than CVS - and it's age shouldn't really have any bearing on whether or not the technology fits your needs. DVCS is a more flexible solution for disjoint/separated teams or teams that go a while without repository access. If your team fits this bill, then I recommend...

Hg. In addition to an Eclipse interface called Mercurial Eclipse, Mercurial has TortoiseHg (a sister to the handy TortoiseSVN plugin) which is a Windows Explorer layover tool. Because you can't live your entire life inside of Eclipse - TortoiseHg is a great way to have repository visibility in the Windows world. Hg is reputed to be a little bit simpler than git, and as mentioned above it is more Windows friendly.

dls 2009-08-12 19:09:32

Fair point about technology's age. I've used SVN quite a bit and to me it just doesn't provide those benefits I'm looking for right now: local commits, each repository also serves as a backup etc.I've tried Mercurial Eclipse with Galileo and it seems to be totally broken which isn't exactly convincing. I quess it might work with the older versions but it looks like for real work I would have to choose NetBeans if I want to use Mercurial. I love Mercurial's simplicity compared to Git, but the Eclipse issue might force me/us to learn Git instead.

auramo 2009-08-12 19:41:31

FYI: Git has TortoiseGit, Git Extensions, and (in early stages of development) git-cheetah which is to be muiti-platform.

Jakub Narębski 2009-08-12 21:35:43

@auramo: it's true that SVN doesn't provide all the benefits of more modern architectures but on the other side it's much easier to switch from CVS to SVN: less re-learning, more similar structure and excellent tool support. That being said: if you switch now, looking further than "just" SVN is definitely not a wrong choice.

Joachim Sauer 2010-08-24 09:02:38

+5 A:

There are a couple of problems with this question in my eyes.
1. You are you saying the support within your IDE of choice is the primary selection criterion for a revision control system
2. You are not providing any real motivation for moving off of CVS other than that it's "old"

I can think of a number of reasons why one might wish to move to Subversion or a distributed revision control system (GIT, Mercurial, DARCS, etc). Which one has the best integration with your IDE, however, should in my view be a very minor consideration.

If you're solving a specific problem you have with CVS, you should clearly define what hte problem is and how each possible contender solves (or doesn't solve) that problem. Each option has it's relative strengths and weaknesses. Just doing it to have "better technology" is a misguided effort IMO.

Depending on the size and history of your application, how many subsystems depend on your revision control system (for example at my place of work we have automated build systems that directly invoke certain CVS commands), and how well trained your developers are with the current CVS setup, you may have quite a few headaches in moving to something new.

Zac 2009-08-12 20:48:26

The problem with CVS is that we cannot use the internal hosted version any more. The company-internal group which hosts stopped allowing binary files and the repository size exceeds their quota. The CVS setup had many other - well known- issues which I didn't feel I needed to elaborate here because I thought they are pretty obvious. To name a few: No atomic commits, you can't track individual commits, CVS subdirectories everywhere which are always in the way (same problem with SVN BTW), Checking whether repo has changed is extremely slow (try with CruiseControl :-)), etc. etc.

auramo 2009-08-13 07:43:35

Okay, that's comforting. As hard as it may be to believe, I've seen plenty of cases where people do pick a technology on the sole basis of something as minor (to me) as IDE integration.If you've though about the actual problems, which it's clear you have, then I don't know that I can offer much. I've personally used Mercurial and the Eclipse Plugin with a decent amount of success. There are a number of comparisons between GIT and Mercurial out there (I won't rehash them as you have google), but to me Mercurial seemed like the better choice. I still say the IDE support is secondary.

Zac 2009-08-14 15:46:43

Mercurial is definitely easier to use for a newbie, or for someone coming from SVN.

auramo 2009-08-14 15:52:37

I think you should judge the whole package; good integration with an IDE can definitively save you a lot of time and head-ache

Eelco 2010-06-10 18:13:13

+9 A:

HgEclipse is another plugin to support Mercurial in Eclipse. Compared to the original MercurialEclipse plugin, it is more feature rich and the project progress is faster. You can learn more here:

http://www.javaforge.com/project/HGE

intland 2010-01-13 12:24:04

Thanks! It also doesn't divide by zero all the time which I appreciate.

auramo 2010-01-27 14:38:05

+1 A:

@auramo not sure if it's the same issue that you had with mercurial eclipse, but ME had errors for me when my workspace path had spaces in it. I changed the path to one without spaces and the plug-in worked fine

edit another thing that through me for a loop was that the console output of hg history was pretty much illegible, but it turns out that at least in the current version you have to manually click the merc 'history' tab to see it layed out quite nicely.

zanpaktou 2010-01-24 17:01:45

+1 A:

I've recently tried out the Eclipse plugins (MercurialEclipse and eGit) and at the time of writing MercurialEclipse (v. 1.6.0) wins hands down. For everyday work I can't recall ever having to leave Eclipse to do "mundane" tasks like branching, switching branch/changeset, solving merge conflicts, viewing changeset graph, committing, etc.

We have chosen Mercurial (over Git) solely on the frontends (TorotiseHg and MercurialEclipse) being available in Windows.

MdaG 2010-08-24 08:59:49

ansaurus

tags:

views:

answers:

Which has better Eclipse support: git or Mercurial

related questions