Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

EclipseLink/Build/Git

< EclipseLink‎ | Build
Revision as of 14:51, 26 October 2011 by Eric.gwin.oracle.com (Talk | contribs) (To be decided)

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 definately 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.
  • We need to decide whether to archive our SVN repos as reasd-only, or migrate our history into Git.
  • Is the tooling is sufficient for our development needs (Egit/JGit).
  • based upon comments regarding Hooks put in place on Git commits for IP cleanliness, it is possible that there may be compatability issues using the windows platform (unconfirmed).
  • Mid-end of 2012, would coincide with the beginning of the post-Juno release. This means this project should be ongoing in parralel to Juno, with the cutover occurring directly after release.
  • Git uses the concept of "changesets" 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.
  • 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.

Back to the top