Bureaucrats, confirmed, Administrators
4,558
edits
Changes
Jump to navigation
Jump to search
Git/migrating to git (view source)
Revision as of 14:22, 24 September 2015
, 14:22, 24 September 2015Modified version of the outline at https://wiki.eclipse.org/Git/Migrating_to_Git
A summary of the steps for migrating your version control system to git from subversion
<ol>
<li> Discussions with stakeholders, project lead
<li> Leverage the resources and expertise of prior large migrations including [https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git Pro Git 2nd Ed.] [https://wiki.eclipse.org/Git/Migrating_to_Git Eclipse Foundation], [https://blogs.atlassian.com/2013/01/atlassian-svn-to-git-migration-human-side/ Atlassian], [https://blog.wikimedia.org/2012/02/15/wikimedia-engineering-moving-from-subversion-to-git/ Wikimedia Foundation], [https://www.eclipsecon.org/europe2013/tale-about-big-svn-git-migration EclipseCon proposed talk by Max Anderson], [https://groups.drupal.org/drupal-org-git-team Drupal], PostgreSQL, and Pentaho. Be sure to plan for the "before", the actual migration, and the "after" migration work.
<li> Understand the concept of Git repos
<li> Know the caveats
<li> Plan and structure your Git space
<li> Decide what to do with your existing code
<ol>
<li> Archive your current CVS or SVN repository
<li> Import your history into git
</ol>
<li> Do the migration.
<ol>
<li>Migrations must include at least the following details
<ol>
<li> Migration timeline
<li> mapping of current code to new Git repos
<li> decision regarding existing code (archive or import)
<li> A description for each repository (which will be visible in the web view)
</ol>
<li>Use/learn from recipes for LARGE migrations <ref>[https://github.com/maxandersen/jbosstools-gitmigration Max Anderson's recipe for migration of the JBoss Tools repos]</ref>
</ol>
<li> Importing your SVN history into Git
<ol>
<li> Using svn2git on a remote server
<li> Using svn2git on build.eclipse.org
</ol>
<li> Convert .svnignore to .gitignore
<li> Git Team Provider for Eclipse / Developer Tools setup / Client and End User configurations
<ol>
<li>
<li> Add EGit to Eclipse
<li> [https://netbeans.org/kb/73/ide/git.html Netbeans natively supports Git] since v7.1
</ol>
<li> Git Resources
<li> Git Task Force
<li> Update references in your product brochures, project documents, websites, systems, reference materials and procedure documents to reference the new systems. This step can be ameliorated if in the beginning you reference code in a generic way such as "code.example.com" where you can then link to various aspects and implementations of your code systems; rather than naming them specifically based on technology or implementation.
</ol>
== Caveats ==
A single Subversion repository almost always contains multiple "projects" - each with it's own 'trunk', 'branches' and 'tags'. One thing you'll find moving from SVN to Git is that Git repositories aren't designed for multiple projects in the way that SVN is used. Separate projects in a single SVN repository should be moved to different Git repositories. So you'll want to split up a multi-project SVN repo when moving to Git. A tag or branch in a Git repository is always global to the repository -- so a good rule of thumb is "what makes semantic sense as a single version".
== Benefits ==
git to git migrations are incredibly easy... at least for the core git repository functions. Just add another remote to push/pull. This means that if you wish to change your git infrastructure to use a different system, the work involved will mostly be about the extra features bundled with the system (e.g. web viewer, code review, etc.) and integrations.
{{References}}
<ol>
<li> Discussions with stakeholders, project lead
<li> Leverage the resources and expertise of prior large migrations including [https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git Pro Git 2nd Ed.] [https://wiki.eclipse.org/Git/Migrating_to_Git Eclipse Foundation], [https://blogs.atlassian.com/2013/01/atlassian-svn-to-git-migration-human-side/ Atlassian], [https://blog.wikimedia.org/2012/02/15/wikimedia-engineering-moving-from-subversion-to-git/ Wikimedia Foundation], [https://www.eclipsecon.org/europe2013/tale-about-big-svn-git-migration EclipseCon proposed talk by Max Anderson], [https://groups.drupal.org/drupal-org-git-team Drupal], PostgreSQL, and Pentaho. Be sure to plan for the "before", the actual migration, and the "after" migration work.
<li> Understand the concept of Git repos
<li> Know the caveats
<li> Plan and structure your Git space
<li> Decide what to do with your existing code
<ol>
<li> Archive your current CVS or SVN repository
<li> Import your history into git
</ol>
<li> Do the migration.
<ol>
<li>Migrations must include at least the following details
<ol>
<li> Migration timeline
<li> mapping of current code to new Git repos
<li> decision regarding existing code (archive or import)
<li> A description for each repository (which will be visible in the web view)
</ol>
<li>Use/learn from recipes for LARGE migrations <ref>[https://github.com/maxandersen/jbosstools-gitmigration Max Anderson's recipe for migration of the JBoss Tools repos]</ref>
</ol>
<li> Importing your SVN history into Git
<ol>
<li> Using svn2git on a remote server
<li> Using svn2git on build.eclipse.org
</ol>
<li> Convert .svnignore to .gitignore
<li> Git Team Provider for Eclipse / Developer Tools setup / Client and End User configurations
<ol>
<li>
<li> Add EGit to Eclipse
<li> [https://netbeans.org/kb/73/ide/git.html Netbeans natively supports Git] since v7.1
</ol>
<li> Git Resources
<li> Git Task Force
<li> Update references in your product brochures, project documents, websites, systems, reference materials and procedure documents to reference the new systems. This step can be ameliorated if in the beginning you reference code in a generic way such as "code.example.com" where you can then link to various aspects and implementations of your code systems; rather than naming them specifically based on technology or implementation.
</ol>
== Caveats ==
A single Subversion repository almost always contains multiple "projects" - each with it's own 'trunk', 'branches' and 'tags'. One thing you'll find moving from SVN to Git is that Git repositories aren't designed for multiple projects in the way that SVN is used. Separate projects in a single SVN repository should be moved to different Git repositories. So you'll want to split up a multi-project SVN repo when moving to Git. A tag or branch in a Git repository is always global to the repository -- so a good rule of thumb is "what makes semantic sense as a single version".
== Benefits ==
git to git migrations are incredibly easy... at least for the core git repository functions. Just add another remote to push/pull. This means that if you wish to change your git infrastructure to use a different system, the work involved will mostly be about the extra features bundled with the system (e.g. web viewer, code review, etc.) and integrations.
{{References}}
