To GIT or not to GIT

SVN2GIT

Prologue (or TL;DR)

Lately (and not for the first time), I’ve been asked by a customer - as an expert in migrating SVN projects into GIT - to help to explore the reasons for performing the migration to those that are not sure whether this is not just a trend to follow.

All due you can’t just ignore such a bold trend and stick to what you’re used to for many years (‘why should I replace something that works for me just fine???’), especially if you want to adjust to Agile and time-to-market methods, there are good reasons for performing such migration.

Still, not everyone should switch from SVN to GIT, but if you do consider or already decided to perform the migration, please read this article before you start.

GIt vs SVN

Why should I not migrate from SVN to GIT?

Here’s a (not complete due) list of possible reasons to consider not performing the migration:

  1. No one in the organization is a GIT-expert or GIT-export-to-become - GIT is not trivial and you must have at least one troubleshooter around for cases you’ll need one.
  2. The project-code-tree includes too many binary-files and/or it is a monolith and you prefer to leave it as such.
  3. There are only one or few developers involved in the project and client-server approach is what they used to and prefer.
  4. GIT has a significant learning curve that not everyone is ready for.

To GIT or not to GIT? To GIT!!!

There are many reasons why a project should migrate to GIT (whether it is from SVN, from any other SCM or from scratch). I’ll list the most important ones as I see it, and I strongly recommend that - if you decided to perform the migration - you won’t stop reading after this section and continue reading the article for performing the migration correctly.

  1. Dramatic increase in operation speed. It is hard to imagine how fast is GIT comparing to SVN, but it is! And it is not just because most of the work is done locally on your desktop/laptop, but also the network operations are much faster as well.
  2. Cheap branch operations. Merge in SVN is something that developers try to avoid as much as possible. The same goes for branch switching and other branch-related operations. With GIT those operations become almost a non-issue.
  3. Better integration with Agile and process tools. The software world becomes more and more an Agile-world, and GIT is much more ready for it than any other SCM.
  4. Cherry picks. I used to say that GIT cherry picks are the magic reason to use GIT for, but then I discovered that cherry picks can be done in SVN as well - but it is not as good as in GIT. In short - cherry-pick is the ability to merge a single commit or a range of commits without the need to merge a whole branch into another branch. This is usually done when you perform a fix on a certain branch and you want to take the-fix-only into other branches.
  5. Full history tree available offline. For comparing code to other versions of it, along with other history-related operations, SVN requires heavy network actions. With GIT it is all done locally, what makes it fast and cheap.

GIT vs. SVN

Here is a list of topics to consider when comparing GIT to SVN:

  1. Git is a distributed version control system (DVCS) while SVN is a centralized version control system.
  2. GIT is much faster – most actions are done locally (diff, view history, commit changes, merge branches, switch branches) and network actions are done compressed.
  3. SVN is easier to understand.
  4. SVN allows better check out of subtrees.
  5. Git branches are simpler and less resource heavy than SVN’s.
  6. Walking through versions is simpler in SVN because it uses sequential revision numbers (1,2,3,..); Git uses unpredictable SHA1 hashes.
  7. Git branches carry their entire history.
  8. Only SVN manage folders.
  9. Different access control method.
  10. Git’s repositories are much smaller than SVN’s.
  11. Git provides better auditing of a branch and merges events.
  12. Git’s repo file formats are simple, so repair is easy and corruption is rare.
  13. Git repository clones act as full repository backups.
  14. SVN’s UI is more mature than Git’s - even due GIT tooling world is growing fast.

Do it right

Do it right!

Tikal DevOps group (which I’m a member of it) helped to perform a migration to GIT (mostly from SVN and CVS) to a large number of customer-projects. A few years back I’ve created a guidelines form (it is a Google Docs document) that helps me and others to plan and perform the migration.

There are many issues to consider while planning the migration. Here’s a partial list of those issues:

  • Learning curve - consider a course or a training of GIT to all future users of it.
  • Binary files - consider moving all binary-files to an artifacts-repository (e.g. Artifactory, Nexus) or - in the worse case - use GIT-LFS.
  • Empty folders - if SVN repository contains important empty folders, override the issue by placing empty files (e.g. .gitkeep) in those folders.
  • Ignore lists - create .gitignore files for all GIT repositories in order to replace the ignore lists which SVN keeps as attributes.
  • Access control - SVN access control is much different than GIT access control.
  • Commit history - It is very recommended not to migrate the commit history of SVN. Instead, keep the SVN repository in read-only mode for reference.
  • Hosting server and services - Choose the right hosting service and server for GIT. You can refer to GIT hosting service presentation for helping you make the right decision.
  • Integration with other tools - plan how you’re going to integrate your GIT repositories with other tools (e.g. Atlassian tools such as Jira, IDEs, Build tools).
  • Branching model - decide on the branching model you’re going to use (e.g. GitFlow).
  • Versioning - decide on the versioning method you’re going to use. Please notice that GIT commit hash is unpredictable.
  • CI/CD (including hooks) - plan the whole CI/CD procedures you’re going to use and how GIT integrate into it.
  • Co-existence of SVN and Git during the migration - during the migration GIT and SVN may co-exist and this requires special considerations.

And lastly, here are my main recommendations for such migration:

  1. Migrate only if you and your organization are ready for it!
  2. Migrate only if there are Git experts around or Git-experts-to-become.
  3. SVN-to-Git migration is better done along with other migrations (e.g. better CI/CD and switching to a better build tool), cleanups (e.g. remove binary files) and refactoring (e.g. move to separate components repositories)
  4. Plan the whole migration process in advance (including side-by-side Git and SVN phase)
  5. Don’t migrate the SVN-history into Git! Keep SVN repository in read-only mode instead.

Darth

Let the GIT force be with you! … and we can help as well: DevOps@tikalk.com.

Thank you for your interest!

We will contact you as soon as possible.

Send us a message

Oops, something went wrong
Please try again or contact us by email at info@tikalk.com