Only 1 more day until Eclipse Helios is release and we are down to my Top 2 features.

Over the life of Eclipse (Jeff McAffer tells me that he’s been working on Eclipse since 1999) a lot has changed. Eclipse started its life inside OTI/IBM. In November 2001 the Eclipse Consortium was announced and Eclipse was released as ‘Open Source’. For the next few years Eclipse grew, but was still mostly supported by a few large companies. New projects were proposed, new committers came on board, and Eclipse became the dominate player in the IDE space.  But as the popularity of Eclipse grew, so did its diversification. Then in April 2010, David Carver noticed that the number of active individual committers (those not associated with any particular company) was tied with IBM for the top spot.

What does all this mean and what does this have to do with the Eclipse Helios release? Well, as Eclipse continues to diversify, the Eclipse foundation will need a software revision control system that supports this diversification. The Eclipse Helios release marks the beginning of this transformation. Number 2 on my Top 10 List is: Git Support at Eclipse.

Three important components make up the Git support at Eclipse: JGit, EGit and the Git Infrastructure. JGit is a pure Java library implementation of Git version control system. JGit is licensed under the EDL has a number of users, including the Netbeans Git support.

EGit is the Eclipse tooling, and is build on JGit. There is currently support for a number of Git features:

History view:

Repository View:

Patch Support:

The JGit / EGit team has excellent documentation and there is some great information on Git in general.  Git is being worked on by Matthias Sohn, Shawn Pearce, Chris Aniszczyk, Mathias Kinzler, Stefan Lay, Robin Rosenberg and Christian Halstrick.  However, a really big thank-you goes out to the past (and present) committer reps for bringing Git to Eclipse.  The initial Git contribution provided a number of unique licensing challenges that required unanimous approval from the Eclipse board of directors.  Git at Eclipse would not have been possible without their hard work.

In addition to the tool support, Eclipse.org has rolled out Git infrastructure for the community to make use of. There are Git mirrors for Eclipse projects and even Git repositories that some projects have started to migrate too. The big thank-you goes out to Denis Roy and Wayne Beaton for this.  Git really is the future of Eclipse, and if all goes as planned, Git will be on my Top 10 List again next year.

Tags: egit, git, helios, jgit

Git has been gaining some traction in the Eclipse community as of late.

From the birth of the EGit project at Eclipse and the recent approval of JGit to be hosted at Eclipse as a sub project of the EGit project, good things are coming. Why should you care about Git?

Git is pretty popular these days as evident by some of the open source projects out there using Git:

• Linux
• KDE
• Qt
• Android
• X.org
• Wine
• VLC
• OLPC
• OpenAFS
• Ruby
• Perl

Apache is even rumored to be switching, at the moment they have a public GIT mirror.

Git is also fast and efficient. In some of my testing, Git produced significantly smaller repositories than SVN did. In terms of speed… I think Git’s ability to do branching cheaply is one of its biggest assets. In the end, I think the most important feature of Git is that it significantly lowers the barrier to contribution. People are able to easily branch your work and you can pull at a later time. I’m not a Git expert by any means yet, but here are some things that have helped me along my Git journey:

• Read the free Pro Git book
• Read Why you should switch from SVN to Git
• Read http://whygitisbetterthanx.com/

In the Eclipse world, I see a move towards Git as the smart thing to do. It would make it easier for the Eclipse community to contribute code versus our current model. It would also help the many companies out there that maintain their own copies of Eclipse and patch things as necessary because of their release cycles. The more I look at it, I can’t come up with many reasons why Eclipse shouldn’t move to Git. Here are some current happenings:

• A vserver is being provisioned with Git and Gerrit installed
• A read only GIT mirror of the Eclipse codebase is being setup

If Git is important to you at Eclipse, I encourage you to get involved with the EGit project via their mailing list.

Tags: eclipse, git, jgit

I used what little free time I had over the holidays to catch up on the recent developments in source control management systems, which have been quite interesting to follow. Especially the arrival of Distributed Version Control Systems has caused quite a buzz in the software development industry.

Somehow Eclipse as a whole totally missed the SVN boat. Only in the last year has there been any uptake of Subversion within the Eclipse Foundation itself. And although there are two separate plugins (and by my count at least 3 different adapter libraries) it still doesn’t feel quite as solid as the CVS counterpart. But the writing is on the wall: CVS does not fulfill all the needs we expect from a contemporary source code management system. And while I have been a long-time fan of Subversion (atomic-commits and rename tracking, yay!) I still feel that maybe the time of centralized source control is over, especially in an open source environment. Doug Schaefer seems to agree. Distributed source control makes it much easier for potential contributors to get started. Experimental and “investigative” branches are easier to manage, and things like feature branches are more easily merged again. While it’s not all roses either (partial checkouts and IP-taints anyone?), but it does make the the development process quite a bit better. And isn’t that one of the main goals of the Eclipse Foundation?

So over the holiday I checked out (quite literally) the latest egit sources and played around with it a little. I must say that I came away quite impressed. Although there are still some features missing, the core looks very solid and usable.

The history of the egit project

Because the source for egit is openly available, it was very easy for me to “grok” the innards of the git system. My C is getting a little rusty these days, so a Java implementation made a much better reading experience for me. Debugging and Ctrl-clicking as well for that matter. With the core jgit library in hand, I even tried to implement a versioned POJO persistence store, but that’s a story for another time. What struck me most about git was the raw and brutal simplicity and the resulting elegance of its design. Believe it or not, but git only knows four different types of objects. Java’s “hello world” uses about that many! Another neat thing is the hash value that is calculated for virtually everything you do. When I first readabout this feature, I was quite skeptical to be honest: For starters, I don’t want to type 40 letter strings anytime I want to reference a revision and secondly, what about collisions? Well I worked out the math on that one, and what it comes down to is this: by the time I will create my first collision I will have been struck by lightning three times over and have survived the sun going supernova. And as for typing in those hashes, well you need it less than you would think and even then you usually only need the first few letters to make it unambiguous.

So kudos to the egit team for the great and continued work on this project. There even is an egit project proposal up. Although git support was postponed in the last board meeting, I still think this a step in the right direction and I’m looking forward to future developments.

Tags: eclipse, egit, git, jgit