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

Difference between revisions of "Platform-releng/Juno Git Migration"

(Git Ant task)
Line 36: Line 36:
 
Equinox launcher natives:
 
Equinox launcher natives:
 
* Similar to SWT above
 
* Similar to SWT above
 +
 +
== Git Ant task ==
 +
We need a Git Ant task that invokes JGit for fetching SWT source as part of SWT hudson build. See {{bug|321237}}. This is apparently done (need to confirm it is available and works for us on all platforms).
 +
 +
= Resolved issues =
  
 
== Git repository granularity ==
 
== Git repository granularity ==
Line 48: Line 53:
 
* Incubator
 
* Incubator
  
== Git Ant task ==
+
== Tagging process ==
We need a Git Ant task that invokes JGit for fetching SWT source as part of SWT hudson build. See {{bug|321237}}. This is apparently done (need to confirm it is available and works for us on all platforms).
+
* Build tags everything that is in master
 +
* If you don't want to contribute to build, put it in another branch
  
 
= Issues for after migration =
 
= Issues for after migration =
 +
== 3.x/4.x migration ==
 
* Renaming of e4 bundles
 
* Renaming of e4 bundles
 
* Stitching in R4 branch of org.eclipse.ui.workbench that is in separate location
 
* Stitching in R4 branch of org.eclipse.ui.workbench that is in separate location
  
Git fetch factory still uses command line git
+
== Including eGit in Eclipse SDK ==
** Not yet ported to JGit but that's not blocking us
+
  
Eclipse-Source-Header support for Git still missing
+
Traditionally we have included everything in the SDK needed to build the SDK. This implies including EGit/JGit in the Eclipse SDK. However this introduces a cyclic build dependency which always causes problems and introduces end-game risk. We need to reconsider this policy of including everything we need. Using p2 having multiple "root" features installed and updating them on an ongoing basis is no longer painful. The advantage of putting everything into a single build is perhaps outweighed by the pain of build-time dependency entanglement.
** Needed for Juno but not for Git migration
+
  
= Timing =
+
Recommendation: Remove all VCM support from the Eclipse SDK and users install what they need separately.
  
 +
Need to discuss this at the PMC call and architecture meeting to find consensus
  
 +
== Git fetch factory ==
  
 +
The Git fetch factory still uses command line git. This is not yet ported to JGit but that's not blocking us because our builds all run on a single platform (Linux). Unclear who will do this and when it will happen. In the long term this will be beneficial to remove a specific platform dependency from our build process.
  
Including eGit in Eclipse SDK
+
== Source headers ==
* Need project leadership discussion to ensure we can coordinate releases
+
 
* Need a stable repository that we can consume from
+
Eclipse-Source-Header support for Git still missing. This is needed for Juno but not for Git migration. Consider PDE plan item to support this (possibly in collaboration with EGit team)
* Not something to tie to migration timeline
+
 
* Do we even need to include it at all
+
= Timing =
* Discuss at arch meeting
+
 
 +
June 13-24:
 +
* Run test migrations and test builds
 +
* SWT investigating migration of SWT builder
 +
June 27-July 1:
 +
* Migrate Equinox repositories to Git
 +
July 11-15
 +
* Migrate Eclipse TLP repositories
  
 
Remove org.eclipse.team.cvs feature from SDK?
 
Remove org.eclipse.team.cvs feature from SDK?
Line 80: Line 95:
  
 
Need author information for all committers past and present for migration tool
 
Need author information for all committers past and present for migration tool
 
Tagging process
 
* Build tags everything that is in master
 
* If you don't want to contribute to build, put it in another branch
 

Revision as of 16:58, 9 June 2011

The Eclipse top-level project is investigating migration to Git during the summer of 2011. Development towards both Juno and Indigo SR1 would continue in Git after migration

Current state

  • We have been doing test builds using p2 fetched from the git mirror automatically created by the foundation
  • This mirror is missing some tag/branch information so isn't reliable for test builds
  • Denis set up area where we can run test migrations to Git
  • Kim has run a test migration which she will then run a test build on
  • Still need to figure out how to exclude binaries from the migration to Git step
  • Then we can do a full test migration of all repositories and run a complete build

Issues blocking migration

Binaries in repositories

We currently check binaries into CVS in several places:

  • Base builder
  • SWT fragments
  • Equinox launcher and security fragments
  • Misc platform binaries such as file system, resources

These binaries bloat the repository which will make cloning repositories painful for developers. We decided on the following action:

  • Binaries are instead published to a p2 repository (the native binaries repository)
  • Build consumes binaries from p2 repositories and source from Git
  • These binary p2 repositories are only used as build input and not intended for wider consumption
  • Retention policy likely to be a single release for these binary repositories. Can always regenerate old binaries from source in the future so no need to retain them forever

Bootstrap process for the base builder becomes:

  • wget a stable platform runtime binary (milestone)
  • invoke command line p2 director to get the base builder from milestone repository
  • We will need a base builder product (bug ref??)

SWT build process:

  • SWT has a hudson build for generating their native binaries
  • Builder will fetch native source from Git using Git Ant task
  • Builder will push resulting fragment to the Eclipse project native binaries repository

Equinox launcher natives:

  • Similar to SWT above

Git Ant task

We need a Git Ant task that invokes JGit for fetching SWT source as part of SWT hudson build. See bug 321237. This is apparently done (need to confirm it is available and works for us on all platforms).

Resolved issues

Git repository granularity

We decided on a single Git repository per ACL. One common Eclipse TLP repository for doc and map files.

The same holds for Equinox, although Tom considering folding security component into bundles due to lack of active committers. The repositories for Equinox will be:

  • Framework
  • Bundles
  • p2
  • Security (maybe)
  • Incubator

Tagging process

  • Build tags everything that is in master
  • If you don't want to contribute to build, put it in another branch

Issues for after migration

3.x/4.x migration

  • Renaming of e4 bundles
  • Stitching in R4 branch of org.eclipse.ui.workbench that is in separate location

Including eGit in Eclipse SDK

Traditionally we have included everything in the SDK needed to build the SDK. This implies including EGit/JGit in the Eclipse SDK. However this introduces a cyclic build dependency which always causes problems and introduces end-game risk. We need to reconsider this policy of including everything we need. Using p2 having multiple "root" features installed and updating them on an ongoing basis is no longer painful. The advantage of putting everything into a single build is perhaps outweighed by the pain of build-time dependency entanglement.

Recommendation: Remove all VCM support from the Eclipse SDK and users install what they need separately.

Need to discuss this at the PMC call and architecture meeting to find consensus

Git fetch factory

The Git fetch factory still uses command line git. This is not yet ported to JGit but that's not blocking us because our builds all run on a single platform (Linux). Unclear who will do this and when it will happen. In the long term this will be beneficial to remove a specific platform dependency from our build process.

Source headers

Eclipse-Source-Header support for Git still missing. This is needed for Juno but not for Git migration. Consider PDE plan item to support this (possibly in collaboration with EGit team)

Timing

June 13-24:

  • Run test migrations and test builds
  • SWT investigating migration of SWT builder

June 27-July 1:

  • Migrate Equinox repositories to Git

July 11-15

  • Migrate Eclipse TLP repositories

Remove org.eclipse.team.cvs feature from SDK?

CVS mirror of Git for maintenance streams

Leave CVS writable until we figure out 3.4.2+ story

Need author information for all committers past and present for migration tool

Back to the top