Jump to: navigation, search

EclipseLink/Build/Git

< EclipseLink‎ | Build
Revision as of 13:49, 12 December 2011 by Eric.gwin.oracle.com (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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.

About Gerrit

Gerrit is a web-based code review system for projects using Git. Gerrit makes reviews easier by showing changes in a side-by-side display, and allowing inline comments to be added by any reviewer. In addition, policies for patch adoption can be set such as: require N +1 votes, of those votes, require M from committers, etc. The mobile phone Android OS uses Gerrit extensively and has a lot of documentation describing the life-cycle of a patch.

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).
    • One repo for foundation, jpa, moxy, dbws; another for examples; another for admin (specs) other docs; separate ones for persistence, asm, antlr, hermes (due to different release/branching strategies)?
  • 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.
      • Same applies for potential core re-factoring.

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.
    • Could use labels instead, but nightly labels seems a bit much.
    • Just date of build doesn't give much meaningful info WRT source though. Would be depending upon source bundles.
  • 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.

Decisions made (fluid)

  • Will migrate post 2.4.0 completion (release ready)
  • Identified as "separate repository" candidates:
    • EclipseLink (core,dbws,jpa,moxy,sdo,parts of utils)
    • javax.persistence
    • org.eclipse.persistence.antlr
    • org.eclipse.persistence.asm
    • commonj.sdo
    • workbench
    • incubation
    • examples
    • docs?
    • project-admin (specs, project admin)?

Action Items

  • Find out what the Eclipse Resource expentiture would be to migrate - Eric
    • Find out if "test migrations" would be too costly
    • What is best methodology for splitting repos (pre or post migration)?
    • Possibly initiate bugs to migrate only our dependencies to separate Git repos (javax.persistence, antlr, asm, commonj.sdo)
    • Need to determin if migration will occur post or pre 2.4.0 release
  • Create bug to migrate EclipseLink Incubation to Git - Doug
  • Once Team as a "sandbox", developers to "play around" with Git/tooling
    • build expertise
    • determine weakpoints in tooling

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