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
(→Git at Eclipse) |
(→To be decided) |
||
| Line 6: | Line 6: | ||
==== 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 | + | * 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. |
| − | * We need to decide whether to archive our SVN repos as | + | * 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). | ||
| − | * based upon comments regarding Hooks put in place on Git commits for IP cleanliness, it is possible that there may be | + | * 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). |
| − | * Mid-end of 2012, would coincide with the beginning of the post-Juno release. This means this project should be ongoing in | + | * 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. |
| − | * Git uses the concept of " | + | * 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. |
* 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. | ||
Revision as of 15:03, 26 October 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.
- 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).
- 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).
- 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.
- 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.
- 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.
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