Home | Eclipse plugins -> MercurialEclipse
+Andrey | About

Eclipse ready

Mercurial (Hg) Eclipse Labs project page plugin for Eclipse

(this is NOT a MercurialEclipse homepage)

This page is my personal page dedicated to the Mercurial (Hg) Eclipse plugin, crafted by Zingo Andersen. 2009 - 2010 I was the leading developer contributing to MercurialEclipse project (until the birth of my son), so I've decided to put here some quick info's.

Why Mercurial? JavaForge project page

It's sounds strange, but today we have few alternatives for the really good version control system (VCS).

What do I mean by good?

  • Reliable. If VCS isn't reliable, it is worthless. If it looses your data (or does not allow you to access it), it is just a crap.

  • Fast. If you spent more time with your VCS as with programming, then you waste you time (and money).

  • Scalable. If it only works fast with less then 10000 files or requires a huge and expensive server to manage them, it will not scale with 1000000 files in the enterprise multi site world.

  • It can branch and merge. Most of professional developers are working in parallel on different branches of the same product. Being able to (automatically) propagate changes from one branch to another is the very important to save you time (and money), because otherwise you have to patch you bug in each and every branch again and again. Some VCS claim that they can branch and merge (like SVN), but merge != merge. It is not enough to copy files to a different folder and say "it's a new branch now". The true merge is if the VCS can track your changes across moved (renamed) files through different release streams. If it can NOT, you will fail to propagate your changes to a different branch immediately after the first refactoring.

  • Usable. If you have to spend days to read cryptic man pages instead of simply doing your work, then you waste you time (and money) again. Basically it means, it has to be integrated into your IDE of choice in the way that you do not need to read any man page at all.

  • Distributed. If you ever wanted to switch to the different branch in few seconds, or commit as often as you like (even while being offline), you must try a distributed (decentralized) VCS.

  • Open for third parties (or even open source). Being open is important, because in most cases you can get better/faster support for open systems. In case VCS is open source, you can try to fix it for your needs.

So which VCS I know personally? Perforce, Clearcase, CVS, Subversion, Mercurial and Git.

Clearcase is very often used in the enterprise world, because it is from IBM. Actually it is not, but anyway, it is expensive enough to buy it, so as IT manager in the big company it is your choice. Personally I hate Clearcase. It is neither fast nor reliable (I've seen 200 people waiting for a single defective server and being unable to simply read their own code), it does not really scale (until you upgrade to fiber glass network and buys some expensive IBM servers) and can not be really used in multi-site environment (it allows you to see the code committed in the other site after a DAY delay, because it need to run synchronization job between sites!), and it is of course closed source. BTW it is wrong to assume that because both Clearcase and Eclipse are from IBM, that Clearcase has outstanding Eclipse plugin. It doesn't. The plugin is a joke wrapper to native Clearcase controls and windows, it is not really integrated into Eclipse. They do not have a simple list of checked out files (can you believe it !?!). The only one thing they do very good is branching and merging, I think this is the best implementation you can buy today. But except this - hey, it's expensive and it is from IBM, so it must be good...

Perforce is a good candidate if you have some money left after the Clearcase deal, but it is neither distributed nor open (but they have good support). So if you do not need distributed VCS, and simply want a good, supported VCS, Perforce is your choice.

CVS and SVN are more or less the same. Some says "SVN is a better CVS", but some says " if CVS was worse, then SVN is even worse" (enjoy the famous Linus video, it is highly recommended). I know SVN better then CVS, so I would say it is neither fast nor it can merge. In this mail thread you can read why it can not merge (short answer: by design). Of course both are not distributed, but at least open source and have perfect (CVS) or less then perfect (SVN) Eclipse support. So if you are alone developer or have one small project with a single branch, SVN is your choice. If you are seriously thinking about multiple branches or really huge projects, don't touch SVN before it is too late. Perforce is your choice then, if you do not want to try Git or Mercurial.

Git and Mercurial are both the most promising, active, feature reach, open source VCS today. If your could not convince your IT manager to buy Perforce (because it is not from IBM), or your IT manager has not already decided to buy Clearcase (because it is from IBM) or you finally found that SVN synchronization and merge tree conflicts sucks, welcome in the world of happy Git/Mercurial users. I think that both Git and Mercurial are very similar and the difference is more or less matter of your taste. Both are extremely fast (they are as fast as your hard drive allows to read files). Try to switch to another branch on SVN - you know what I mean, it takes time. On Mercurial, it is matter of seconds, because all the data is on your local hard disk. Both have excellent branch and merge implementations (which is capable to track changes also for renamed files). Both are distributed (it means they support ANY workflow you like). Both have Eclipse plugins, and here we are finally there.

Git Eclipse plugin (Egit) is in very early state right now, but they are working to improve it at Eclipse, so I hope it will became as good as CVS Eclipse plugin.

MercurialEclipse vs HgEclipse story

Similar to the Egit plugin, MercurialEclipse plugin was in the very early state before the release 1.4 (despite the high version number). To be honest, I found it hardly usable and very buggy, as I've started to play with it (it was around mid of 2009, version 1.3.1096). Because at this time I've started to investigate alternatives for SVN (after I was shocked by the fact that SVN can't propagate changes to renamed/moved files), I've also started to use MercurialEclipse. You've got a couple of errors after few minutes working with a small project, the cache didn't updated its own state, the history and synchronization views was very limited, performance was dog slow for huge projects etc, summary - this was not acceptable state (IMHO). The plugin was feature rich (as Mercurial itself), but sadly, each and every click you've made caused tons of errors and updates on a big project caused Eclipse to freeze for minutes. If it would be my own plugin, I would give it a 0.0.1 version number (nice proof of concept, but not usable for production). If you have ever heard complains about buggy open source software, this was the good example for such case. Tons of functions, but also a lot of dirty code. Pity for Mercurial, that it's Eclipse integration by far didn't reached the quality of the VCS itself.

To make my life easier I've started to fix the issues I found in the plugin. So we have crafted the fist version, which didn't thrown obscure exceptions immediately after the startup and which had fast and predictable cache strategy (1.4.1280). By pure chance, the guys from Intland Software started to investigate alternatives for SVN at same time for they CodeBeamer product development and they also saw that there is definitely a room for improvement in the Mercurial support in Eclipse. This was the beginning of the HgEclipse story (initially Intland forked the original plugin). As they said: "our ultimate long term goal is to provide a viable option for enterprise scale collaboration, based on the Mercurial distributed version control system, the Eclipse Platform and codeBeamer, our distributed ALM platform ". Because it also fits nicely to my own goal - provide my current company a (long term) alternative to the Clearcase, we started to work together on moving Mercurial Eclipse plugin towards enterprise use. So we crafted 1.5.0 with hundreds of fixes and a lot of new features.

P.S.
After 1.5 HgEclipse release I was able to convince Intland to join the forked HgEclipse code with the original MercurialEclipse project - with the 1.6.0 release both projects are joined again.

MercurialEclipse vs MercurialEclipse (restricted access) story (continued).

After success of the joined 1.6.0 MercurialEclipse release Intland silently decided to restrict public access to the 1.7.0 release (don't ask me why).

To update to the 1.7.0 release or pull MercurialEclipse sources, users were forced to have a valid javaforge account. Of course you can get the account for free, but they can also disallow you access to ANYTHING at ANYTIME - like they did it to me.

After my complain about access restrictions and after very short mail conversation about it my account credentials were changed (from hgeclipse to adlv) without any notice, so that I had no access to the project to which I've contributed for two years. How cool is that? This is definitely NOT the right way to maintain a Successful Open Development Community.

While this move was highly surprising for ALL non-Intland committers, I've decided to put both sources and binaries to a new, this time really open project at Eclipse Labs.

We do not want to fork the project again, as the only requirement for Intland is to provide a FULLY OPEN access to both plugin code and update site. Open means NOT RESTRICTED IN ANY WAY. To make sure that everybody can access MercurialEclipse code/binaries, we will maintain the open MercurialEclipse project at Eclipse Labs.

P.S.
To be clear - my intent is not to fork the project again. I don't care if it is hosted by Bitbucket or Javaforge or Eclipse Labs. I simply wish that the code me and many others contributed (under the terms of EPL (Eclipse Public License)) is accessible for everybody.

MercurialEclipse vs MercurialEclipse (restricted access) story (continued #2).

Good news for the new MercurialEclipse community - after discussion on this bug and many comments from MercurialEclipse users Intland has removed access restrictions from MercurialEclipse update site / code. Unfortunately the link on the project page still points to the restricted repository. As I do not have write access to the project wiki anymore, I can't change it. In order to clone the code, you can either clone it from Eclipse Labs project or from "hidden" repo at javaforge (notice the :8000 port):

    hg clone http://hg.codespot.com/a/eclipselabs.org/mercurialeclipse
    or
    hg clone http://javaforge.com:8000/hgeclipse
  

Latest release

The stable MercurialEclipse 1.8.0 version is planned to be released at March 23th. If you are interested in the latest stable version, just use this url: http://mercurialeclipse.eclipselabs.org.codespot.com/hg.wiki/update_site/stable as update site in Eclipse. This update site is open and will be always open.

Here is a brief overview of changes in the 1.8.0 release

  • Better support for linked projects, projects under symbolic links and virtual resources
  • Better indication of what MercurialEclipse is doing in the status area (shows descriptive text rather than the truncated hg command)
  • Better merge editor support (eg content assist inside editable compare editors)
  • Merge changesets show now ALL files changed during merge (not only manually merged)
  • Moved files are now shown as such (and not as a pair or deleted/added files), both in the Synchronize view and in the History view.
  • In the History view you can now better see where moved/copied files are coming from.
  • Added "Team->Search in History..." and "Search->Mercurial Search" menus
  • Added Properties view support for history and synchronize views
  • Added "Properties" menu to changeset/version in History/Sync view
  • Automatic history view refresh and various small history view enhancements
  • lot of bug fixes
Of course there is still room for improvement, so feel free to comment in MercurialEclipse forums, wish new MercurialEclipse features or report bugs in the MercurialEclipse bug tracker.

Links to the Mercurial Eclipse Labs project page stuff

Feedback

Vote for MercurialEclipse at Eclipse Marketplace
or add MercurialEclipse to your stack at Ohloh
Support development of the plugin:

Last changed at: 12.03.2011 9:49