using a DVCS: EGit (Git) or HgEclipse (Mercurial)

If you’re following my DVCS blogseries, then you know that I was testing “how to use Eclipse Team Provider Plug-ins” last weeks.

BTW: last add-on to the series was “How to use Mercurial Repository at Sourceforge with HgEclipse“.

Background of my work was to make the decision which DVCS should we use for redView (Riena EMF Dynamic Views)

and also red-open Software Manufactory

to provide the sources.

EclipseCon is coming with an Extended Tutorial and another Session about redView and the sources should be online😉

BTW: I’ll also talk about Target Platform and cool Views to inspect your Plug-Ins and about Logging in OSGI Enterprise Applications.

Back to DVCS: From my POV there are no big differences between Git and Mercurial. But I didn’t compare each feature of Git or Mercurial to make my decision – I was only…

… looking for an easy-to-use Eclipse Plug-in

Both Plug-ins are under heavy development and become better and better after each nightly build.

The goal for me was to do all (or most of the) work without using the commandline.

I also wanted to work with Repositories inside the workspace, local repositories and also from remote servers using ssh. Pushing to / pulling from and creation / initialization should all be done from inside Eclipse.

decision done: HgEclipse (Mercurial)

we’ll use Mercurial as DVCS and HgEclipse as Team Provider Plug-In for redView and red-open.

Reason: We could do all what we want without the use of commandline. Some wizards are more compact then from EGit – per ex. you can add and commit in one step. Biggest drawback was the missing Pull and Merge from EGit which is (from my POV) essential using a DVCS – also no Rebase found.

I also missed a view to manage the Repositories. In the case of redView we develop, test and run under different OS to be sure that all works well. We’re working with a tree of repositories: workspace Repositories from OSX, Windows and Ubuntu (can be run from one machine using OSX and Parallels). All these workspace Repositories are pushing / pulling to/from another Local Repository on the same Mac or another one from LAN. And finally changes must be Pushed to / Pulled from a remote ssh repository at SourceForge or BitBucket. To make it even harder there will be customer projects not open to the world and running under Ubuntu as ssh remote Repositories.

Without easy create, init, push, pull, branch, rebase, synchronize between workspace-repos, local repos, ‘open‘ remote ssh repos and ‘closed‘ ssh remote repos this would be a nightmare. Thats the reason why I was looking for best comfort to do it all from inside Eclipse – and it’s not a feature compare of Git or Mercurial. At the time of writing HgEclipse supports more features of a DVCS then EGit.

One thing is not so easy using HgEclipse: Installation of ssh together with Mercurial on Windows. But this is a one-time Installation detail and must not be done daily.

Eclipse Projects will use EGit (Git/JGit)

Perhaps you ask: why Mercurial ? Didn’t you know that sooner or later Eclipse projects will use EGit / JGit ? Yes – I know and I’ll of course use EGit to access Eclipse Projects. But I was looking for a solution working now and resolving the needs of our workflows. Working with DVCS you get much freedom how to organize and use your repositiories where you can easy push / pull around between all of them. This won’t be always easy to solve – but the tool you’re using should be.

I really appreciate the hard work from EGit / JGit team be done last months and there’s much to do until release of Helios. Thanks for fixing bugs and I’ll support you with testing and reporting issues. Maybe in some months the world looks different – there are some ways to convert hg to git ;-) http://hg-git.github.com/ or fast-export. I’ll try these converter – projects after EclipseCon to provide redView’s and red-open’s sources also as Git Repositories.

Thanks to Eclipse: if you have to work with source repositories from different providers like CVS, SVN, Git or Mecurial – they all can friendly co-exist🙂

I’ll continue working on the blog series about DVCS and report from my experiences using HgEclipse and EGit. Now lets start the wonderful new world of distributed version control systems😉

3 responses

    • Chris, I know😉

      … and I like the pure-java implementation of JGit/EGit, which eases working with ssh

      hope you understand my decision…

      cu at eclipsecon

      ekke

  1. Thanks. Good article. Your comparison is open and fair, I think.

    I have trouble with evaluating a tool on presentation alone: the presentation is not the function, even though it appears to be. I know you want something that is more fully integrated into your IDE and that is your primary decision point. How is that NOT like judging a book by its cover?

    For developers, the dvcs systems available today have a different interaction model than the centralized systems. Which interaction model are the current tooling based from? I have a hunch they lean more towards the interaction model of the centralized systems (for a few reasons). If this is true, then there is ‘good cause’ to sidestep the tooling: to participate in the possible interactions offered by the decentralized vcs. So, at this stage, I think there is a good reason to look around the edges of the IDE veneer to the command line.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: