Jump to: navigation, search

Git/Migrating to Git

< Git
Revision as of 11:51, 31 March 2010 by Denis.roy.eclipse-foundation.org (Talk | contribs) (Plan and structure your Git space)

Eclipse projects currently using CVS or SVN may migrate their repository to Git. Here is an outline of the steps:

Talk to your community, project lead

Your project lead(s) needs to endorse the move to Git. Inform your community about the desire to migrate. Keep them informed on the plan and the progress.

Understand the concept of Git repos

Since a Git repo is not the same as a CVS or SVN repo, we assume you understand the Git repository concept. More information can be found on the Git page.

Know the caveats

Git is new at Eclipse.org, and some of our existing tooling may not yet support Git. However, we expect that most of these issues will be resolved in time.

  • The Web front-end to Git is not, and will not be hosted on ViewVC. Git is hosted at http://git.eclipse.org/.
  • Git is not yet included in the Dash tools, such as the Commits explorer.
  • Git may not be fully integrated into the Eclipse build infrastructure.
  • Due to our rigorous IP process, the Eclipse.org use-case for a DVCS is different than that of other Open Source organizations. For this reason, an update hook is installed on all Git repositories to ensure a clean IP provenance. See Git#Committing_and_pushing for more information.

Plan and structure your Git space

  • Webmaster will create a directory on git.eclipse.org to store your Git repositories. Although Webmaster can create your Git repos for you, you are free to do this yourself.
  • Decide on a timeline: webmaster needs exclusive access to your CVS/SVN repo to import it (if that is what is decided). This will disrupt project operations. Choose a timeline to minimize impact.
  • Now is a great time to refactor your code structure. Map the current CVS/SVN directories, modules, plugins, etc. to their new home in Git. Typically, one Git repository (.git) is created for each logical unit, or grouping of code -- a plugin, a connector, a component, and so on. For instance, the Babel project ViewCVS has one CVS repository which contains a server component and a plugin component which, in turn, contains several modules. Here is one example:
   ServerRepo: org.eclipse.babel.server.git
   URL: git://git.eclipse.org/babel/org.eclipse.babel.server.git

   Plugin Repo: org.eclipse.babel.build.git
   URL: git://git.eclipse.org/babel/org.eclipse.babel.build.git
         will contain directories: org.eclipse.babel.build.ant, o.e.b.b.core, o.e.b.b.ui
   Plugin Repo: org.eclipse.babel.core.git
   URL: git://git.eclipse.org/babel/org.eclipse.babel.core.git
   Plugin Repo: org.eclipse.babel.editor.git
   URL: git://git.eclipse.org/babel/org.eclipse.babel.editor.git
   Plugin Repo: org.eclipse.babel.runtime.git
   URL: git://git.eclipse.org/babel/org.eclipse.babel.runtime.git

Decide what to do with your existing code

You have two options for migrating your existing codebase to Git:

Archive your current CVS or SVN repository

  • Webmaster will flag it as read-only.
  • Commit the HEAD stream into Git.
  • Start with a fresh, clean Git repository while preserving CVS/SVN history in its original state.
  • When, and if the CVS and/or SVN service is retired at Eclipse.org, the read-only repositories will be zipped and available for download as an archive.

Import your CVS/SVN history into Git

  • All your history is migrated to the new repositories
  • Once you are fully operational on Git, webmasters then delete your unused CVS/SVN repo.

Open a Bug

Open a bug against Eclipse Foundation > Community > Git requesting the migration. Make sure your project lead is CC'd and add a +1 to the bug. Include detailed plans for your migration:

  • migration timeline
  • mapping of current code to new Git repos
  • your decision regarding existing code (archive or import)