EGit/JGit and Mercurial: DVCS in Indigo
Distributed Version Control Systems in Eclipse Indigo.
For many years, Eclipse projects have worked with CVS and SVN as
version control system, and great Team Provider plugins made this
What’s new in the Indigo Release (Eclipse 3.7)? Modern version
control systems are distributed systems (DVCS) and now EGit/JGit
version 1.0 has been release.
Eclipse Projects Will Switch to Git
The decision was made some time ago: in the near future, Git 
will be the default VCS at Eclipse. EGit works perfectly together
with JGit . JGit is a pure Java implementation of Git and is
hosted as a project at Eclipse – the same as EGit. EGit provides
the Team Provider plugin and allows us to use Git functionality
comfortably inside Eclipse. The committers of EGit and JGit worked
hard to release version 1.0 together with Indigo.
Why use a DVCS (distributed Version Control System)
A DVCS is much more flexible:
- developers have a local copy of the repository
- you can work off-line
- fast and easy branching
- forks/clones allow safe read-write without being a
- commits are fast, so you can really commit in short
You’ll find enough resources on the internet to understand how a
DVCS works, so I don’t want to talk about this topic here.
Git and Mercurial
The most important DVCS are Git and Mercurial  (aka hg).
There’s also a Team Provider plugin for Mercurial:
MercurialEclipse.  Now, with the Indigo Release both plugins
have nearly the same functionality and power. Git is something more
complex and allows the user to solve more types of workflows.
Exclusive to Git is a “staging” – state: a step between new files
or changes and the commit itself. You can collect changes at stage
before committing – so it’s something between “prepared to commit”
and commit itself.
Also, Git can work perfectly together with Gerrit  – a Code
Review System – allowing you to push changes at first to Gerrit,
where commits have to be reviewed from one or more other
committers. One of the reviewers can be a build system like
Hudson/Jenkins, so you can be sure that the build runs well before
pushing changes into the real, ‘master’ repository.
For some years I’ve been using MercurialEclipse without any
problems and from my POV it’s easier to use than Git. But of course
in one of my next projects I’ll use EGit 1.0, and compare both. If
you want to place a project at EclipseLabs and also use a DVCS, you
have to choose Mercurial, because EclipseLabs was hosted at Google
Code, which provides Mercurial, but not Git.
There are many hosting systems for Git and Mercurial making it
easy to try some things out: most important are GitHub and
Bitbucket. SourceForge allows projects to use Git or Mercurial.
EGit and MercurialEclipse: the UI
If you’re using a central VCS there’s only the commit command to
store changes into the central repository, whereas commit on a DVCS
only stores changes into the local repository. You then have to
execute Push to move changes into the remote repository, or Pull to
get the changes from there.
Let’s take a look at some of the provided views and menus – at
first the team-options-menu.
Both DVCS provide similar functionality, but the menus are
ordered differently and also some of the used icons are different.
If you are working with both systems at the same time it’s easy to
click the wrong menu item.
“Serve” is an option only available for Mercurial: using an
integrated webserver you can take a look into the local
repositories using a browser. This allows it to be used by team
members without having Eclipse installed.
EGit and MercurialEclipse are both providing a Repository View,
but the structure is different. Some of the features where you have
to use the Team-Options-Menu at MercurialEclipse are placed inside
the repository View at EGit.
Both systems are providing a History View, where you can see in
detail what happened. If everything is not visible, please take a
look at the small toolbar icons inside the view – they switch
functions on and off.
You see that
both plugins have similar functionality – please also take a look
at the preferences. For me it was no surprise, that No .1 in Ian
Bull’s Top 10 list was: EGit/JGit.  As soon as version 1.0 was
out, there were new projects available like gitBlit  and Chris
Aniszczyk has just developed a new git-reflog View  – so work is
going on to make it even better. It will be an interesting year to
watch how more and more Eclipse projects switch to Git.
Git are both powerful and stable Version Control Systems and it’s
easy to test both of them if you’re not sure which one best fits
(5th) part of my highlights will be on UI design –
especially WindowBuilder. For many years I’ve been using
SWTDesigner from Instantiations – Instantiations is now a part of
Google, and Google have donated the sources to Eclipse – a great