|Home | Eclipse plugins ->||+Andrey | About|
(this is NOT a MercurialEclipse homepage)
It's sounds strange, but today we have few alternatives for the really good version control system (VCS).
What do I mean by good?
So which VCS I know personally? Perforce, Clearcase, CVS, Subversion, Mercurial and Git.
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
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
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.
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.
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.
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.
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
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
Last changed at: 12.03.2011 9:49