EclipseLink/Build/Git

About Git

Git is a "Distributed Version Control System" unlike CVS or SVN which are "Centralized Version Control Systems". Basically this means that every developer that 'checks-out' the codebase recieves a full repository complete with all the history. At Eclipse, the origin repository will also act as the central repository. There also are plans to mirror the repositories to GitHub for greater external access.

Migration timeline

The purpose for this page is to centralize information concerning a migration of EclipseLink code from SVN to Git. It has been stated by the Eclipse Webmaster that "Our goal is to have everyone off CVS/SVN by the middle-end of 2012. If you want to move sooner that's cool since it will help you beat the rush I'm sure will happen." Below are issues/considerations that will need resolution.

To be decided

• Git utilizes multiple smaller repositories, rather than a single massive repository. resolution is usually on a per bundle basis, but can be somewhat larger. Examples, Docs, etc should definitely be stored in a separate repository, but since core is integral to most of the other bundles we will need to decide how they should be organized.
  • Recent Git mailinglist threads seem to reverse this position. Stating that the Git repo should be as encompassing as possible (fewer repos is better).
• We need to decide whether to archive our SVN repos as read-only, or migrate our history into Git.
• Is the tooling is sufficient for our development needs (Egit/JGit/Fisheye).
• Mid-end of 2012, would coincide with the beginning of the post-Juno release. This means this project should be ongoing in parallel to Juno, with the cut-over occurring directly after release.
• looking at a code migration, now would be the time to discuss, and define any further restructuring we have planned (like converting to a Maven hierarchy). Given Gits strengths with history and tree merging and configuration the work could actually be done post-migration, but planning should be done beforehand.

Potential Issues

• based upon comments regarding Hooks put in place on Git commits for IP cleanliness, it is possible that there may be compatibility issues using the windows platform (unconfirmed). Symlink related.
• Git uses the concept of "change-sets" rather than revision numbers. This will mean that qualifiers cannot be tied to the built 'revision'. Full Maven conversion would mean the same thing though, so this is a minor issue.
• Windows upper/lowercase filename problems can (have) created issues with Git. Windows configuration can easily generate duplicate directories accidently in Git (One uppercase/ one lower). This then propogates out in pushes to other committers creating situations where commits appear not to have been made, or a pull generates "modified" code. Windows configurations will need to be tightly controlled, or alternate OS (linux) needs to be available for verification/cleanup.

Useful links

Git

http://wiki.freegeek.org/index.php/Git_for_dummies

http://wiki.sourcemage.org/Git_Guide

http://tom.preston-werner.com/2009/05/19/the-git-parable.html

http://progit.org/book/

Git at Eclipse

http://wiki.eclipse.org/Git

http://wiki.eclipse.org/EGit/Git_For_Eclipse_Users

http://wiki.eclipse.org/Git/Migrating_to_Git

http://wiki.eclipse.org/Platform-releng/Git_Workflows#Clone_a_repo

Git Tooling

http://wiki.eclipse.org/EGit/User_Guide