Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "EclipseLink/Build/Git"
< EclipseLink | Build
(→To be decided) |
(→To be decided) |
||
| Line 7: | Line 7: | ||
==== To be decided ==== | ==== 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. | * 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. | * 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). | * Is the tooling is sufficient for our development needs (Egit/JGit). | ||
| − | |||
* 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. | * 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. | * 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 === | === Useful links === | ||
Revision as of 16:11, 2 December 2011
Contents
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).
- 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
Git at Eclipse
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