Git/v.Subversion

How and Why do you migrate from Subversion to Git?

Experience

• Witness large projects such as Drupal convert from Subversion to Git.
• Deployed and converted teams from Subversion to Git (Harvard SEAS)

Advantages

What are the advantages of Git over SVN (especially in the area of merging)? Here is a short list. A fuller Git v. Subversion Comparison is at kernel.org

1. Git isn't (just) 'smarter' meaning the devs figured out better algorithms. It's completely different. It can be said that SVN is multi-user only because they took an approach that works for a single user, and added features to "multiply" it. Sort of like the Windows operating system. On Windows, you have to log out to have another user log in. Git is multi-user the way that Linux is multi-user: it's built that way from the ground up.
2. branch is virtual in svn v. first class object in git
3. 3-way (git) v. 2-way merges by default - simply means that Git finds the common ancestor for you and does the magic to make merging painless.
4. content tracking versus tree + diff tracking = branches are truly lightweight in git.
5. mimic centralized workflow with git; means that you can still have a command-and-control top-down culture; or do whatever you need to do but you aren't constrained as to how code flows in your development organization.
6. stashing. Being able to instantly clean your house for unexpected guests, and then put it back the way you like it as soon as they leave.
7. rewrite history. Squashing commits before pushing them upstream.

Learning curve

What is the learning curve like for developers? Git can be easy for developers if all you want to do is replace the current svn process. e.g. https://people.gnome.org/~newren/eg/git-for-svn-users.html If you want to get more advanced (like stashing which really is not a "feature" of svn) or pulling from other devs repos, then git is very deep and you can dive down as much as you want.

Impact

What is the impact to the existing development and build process?

The impact can be small (replicating the existing process) or since git opens the possibility for different development strategies, you can potentially reshape your development process to something you want to achieve. The build process is independent. Builds (e.g. with Jenkins) can be automatically driven by commits just like a commit hook in Subversion.

Issues

Why do this? What are the issues we face continuing with SVN?

• Dwindling resources who are familiar with svn since we've probably passed the point where the number of developers who use git have surpassed the number of developers who use subversion.
• Continued problems with the difficulty of merging and thus continued problems associated with developers doing "the wrong thing" (copy/paste instead of merge).

History

How much SVN repo history do we bring over into GIT?

Usually bring all your history. If that doesn't seem right, feasible or desirable for some reason, you don't want to svn delete branches since those branches actually still exist in the svn repo. The way to prune upstream is to use svn dupmpfilter. You dump the svn repo, and filter it as it's being dumped. The resulting dump is then imported into git. The drawback to this approach is that you can't continue to interactively and seemlessly track revisions in the svn repo. In other words, it could mean that you have a "hard" cutover rather than a soft rolling cutover to git.

How do we migrate?

Magic git svn clone http://svn.example.com/repo

But the real migration is harder than that.

• user migration/mapping svn log --xml | grep author | sort -u | perl -pe 's/.*>(.*?)<.*/$1 = /' > users.txt
• git svn clone --stdlayout --no-metadata --authors-file=users.txt file:///path-to/svn-repo tmp-git-repo
• git checkout -b local_branch remote_branch
• migrate tags

Overview of the trial project

One potential trial would be to setup GitLab Development Kit, either on bare metal, or using vagrant https://gitlab.com/gitlab-org/gitlab-development-kit