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

+

We decided on a single Git repository per ACL. One common Eclipse TLP repository for doc and map files. See [https://bugs.eclipse.org/bugs/show_bug.cgi?id=345471 bug 345471] for the discussion.

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:

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:

Line 70:

Line 70:

*Incubator

*Incubator

+

<br>

−

+

The&nbsp; [[Git Migration Granularity|Git_Migration_Granularity]]&nbsp; document lists the proposed bundles per repo.&nbsp; (Nested bundles are assumed to be included by indicating the top level directory).

−

The&nbsp; [[Git_Migration_Granularity|Git_Migration_Granularity]]&nbsp; document lists the proposed bundles per repo.&nbsp; (Nested bundles are assumed to be included by indicating the top level directory).

+

== Tagging process ==

== Tagging process ==

Revision as of 14:51, 10 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

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).

Story for maintenance streams

We need to maintain a CVS repository for performing builds on older branches (3.6.2+, 3.5.2+, etc). Until we have a solution for this, we will need to keep our CVS repository writeable after the Git migration. We can delete all content from HEAD in CVS to avoid confusion.

One option we are considering for maintenance is having a read-only CVS repository that mirrors our Git repository. We could then push changes to Git for maintenance streams, and our old builders can pick the change up from the CVS mirror/clone. We need to work with the Foundation staff to see if this is feasible.

Migration script

We need to gather various bits of information to plug into the CVS->Git migration tool:

Need author information for all committers past and present

Figure out the CVS module -> Git repository mapping for all CVS modules

Figure out what binaries to exclude from migration, and how to exclude them

Determine what legacy CVS modules we can omit from migration altogether

Resolved issues

Git repository granularity

We decided on a single Git repository per ACL. One common Eclipse TLP repository for doc and map files. See bug 345471 for the discussion.

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

The Git_Migration_Granularity document lists the proposed bundles per repo. (Nested bundles are assumed to be included by indicating the top level directory).

Tagging process

Build tags everything that is in master

If you don't want to contribute to build, put it in another branch

Eliminate the manual tagging step taken by all teams today

builds should still be map file based

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 (including CVS) from the Eclipse SDK and users install what they need separately.

edit After excluding CVS from the product, the SDK build could still install it and the EGit feature using the director.

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.