Changes

<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 include the "before", the actual migrationitself, and the "after" migration work.

<ol>  <li> Archive your current CVS or SVN repository? <li> Import your history into git? </ol>

<ol> <li>Map users <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 scripted recipes for LARGE migrations <ref>[https://github.com/maxandersen/jbosstools-gitmigration Max Anderson's recipe for migration of the JBoss Tools repos]</ref> </ol>

<ol> <li> Using svn2git If you can migrate using <code>git svn clone</code><ref>https://git-scm.com/docs/git-svn</ref> which is a tool providing a bi-directional conduit of changesets between subversion and git, then good for you! Your project is small and uncomplicated. For larger, more complicated migrations, this tool is not suited for the job. It will take too long, and simply will fail to produce a git repository. I don't understand why Atlassian recommends this approach in their "tutorial" without telling you that it will fail; or at least providing the major caveats. Still, you can read up on a remote serverthe simplistic scenario <ref>https://www.atlassian.com/git/tutorials/migrating-overview</ref>,<ref>https://www.atlassian.com/git/tutorials/migrating-convert/</ref> <li> Using svn2git <ref>There are 2 pieces of software by the same name. The one you want was [https://techbase.kde.org/Projects/MoveToGit/UsingSvn2Git#Getting_the_tools created by the KDE team]. You could use the [https://github.com/nirvdrum/svn2git ruby gem by nirvdrum], but it's going to be slower. Unfortunately the KDE code lived on buildgitorious.org which was bought out by gitlab.eclipse They say they're going to put the code up on archive.org, but it's not there and I wouldn't hold my breath. The good news is that the code can be found and is also referred to as [https://github.com/svn-all-fast-export/svn2git svn-all-fast-export]</ref> <li>Using [[reposurgeon]] - a tool by Eric Raymond </ol><li> Convert .svnignore svn:ignore properties to .gitignorefile (example of why you need to later delete empty commits which reflect properties not code changes)<li> Git Team Provider Verification<source lang="bash">mkdir -p /tmp/verifycd /tmp/verifyfor v in 2.0.0 2.1.0 2.2.0 ; dosvn co $vdone # export git tagscd /tmp/conv/myproj-gitfor v in 2.0.0 2.1.0 2.2.0 ; do git archive --format=tar --prefix myproj-$v/ v$v | gzip \ /tmp/verify/git/myproj-$v-git.tar.gz donecd /tmp/verify/gitfor Eclipse v in 2.0.0 2.1.0 2.2.0 ; do tar xvzf myproj-$v-git.tar.gzdone # compare themdiff -ur /tmp/verify /tmp/verify/git </source> <li>Build <li> Service integrations <ol> <li>JIRA / Issue Tracker <li>ReviewBoard / Code Review <li>Jenkins / Build system <li>SQA <li>OpenGrok / Developer Tools setup Code indexing browser </ ol><li> Client and End User configurations <ol> <li> Create keys, add each to client and server <li> Install / setup TortoiseGit for Windows <li> Add EGit to Eclipse <li> [https://netbeans.org/kb/73/ide/git.html Netbeans natively supports Git] since v7.1 </ol><li> Repository permissions and group definitions, key imports<li> Establish Git Resources<li> Create Git Task Force<li> Update references in your product brochuresliterature, 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.

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 All the separate projects in (from a single SVN repository ) should be moved migrated to different separate 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 split the code into repositories along boundaries that make sense semantically. (Note that git has much better support for including library code into a good rule of thumb project. The feature is called "what makes semantic sense as sub modules". Thus library code can be semantically split out into it's own repository, and that library can be re-used across multiple git repositories. This is like svn "externals" only better.  == Upside ==Once you've established a single git infrastructure for version"control, 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. == Combining git repos ==You might desire to reorganize your code in the migration process. There are several tools which allow you to merge git repositories together.

== Benefits ==* http://search.cpan.org/dist/Git-FastExport/script/git to -stitch-repo git migrations are incredibly easy-stitch-repo] is made for linear repos* This other one [http://search.cpan.org/~book/Git-FastExport-0. at least 105/script/git-stitch-repo by the same name], authored by Philippe Bruhat (BooK) is nonetheless capable of [http://www.ifup.org/posts/the-right-tool-for -the core -job-git repository functions-stitch-repo/ merging two (or more) repositories]* This one, [https://github. Just add another remote com/robinst/git-merge-repos git-merge-repos] is interesting because it talks about taking multiple repositories with more or less the same branches or tags, and merging them at the tag* [https://stackoverflow.com/questions/277029/combining-multiple-git-repositories This post on Stackoverflow about combining multiple git repositories] mentions git-stitch-repo, and also how it gained the capability to push/pullwork with non-linear merge histories. This means It also explains how to do repo merges with git-filter-branch. Note that if git-filter-branch requires you wish to change rewrite your history (breaking SHA1 sums).* The [http://www.kernel.org/pub/software/scm/git infrastructure /docs/howto/using-merge-subtree.html subtree merge strategy page on kernel.org] shows you how to use do this.* https://westmarch.j5int.com/2014/06/splicing-git-repositories-together/ [https://github.com/j5int/jbosstools-gitmigration/blob/master/git_fast_filter/testcases/splice_repos.py Splice Repos] is a different systempython script. It's more recent than some others and a better tool because it's based on fast-export/fast-import <ref>https://git-scm.com/docs/git-fast-import</ref>. It grew out of the [https://github.com/j5int/jbosstools-gitmigration JBossTools git migration] (which itself has some useful info on procedures).* Also, the work involved will mostly be about the extra features bundled [[reposurgeon]] tool itself can assist you with the system (e.g. web viewer, code review, etc.) and integrationsre-organization of your sources.