Praecipio is frequently asked about migrating from various software version control systems to Git-centered tools such as Atlassian’s Bitbucket. Time for some excellent news: this is definitely possible and can be done in a painless fashion! Some organizations confidently plan and migrate by themselves. But … there’s always a “but” … be forewarned - there isn’t an “easy” button. Your success depends upon investing the effort, both in planning and communicating with your teams. However, many organizations prefer using experienced 3rd parties who will focus on doing something not considered an organizational core competency. Praecipio often assists clients in their migrations: our approach is based upon proven tools and processes honed by multiple engagements over the past 15 years.
Nonetheless, there still isn’t an “easy” button and the client’s involvement is integral to the final outcome as unique aspects are often uncovered.
If you still use Subversion - also known as SVN - as your software version control tool, you can be forgiven in believing that you’re alone. Searching the web yields many documents from circa 2012 which often contain phrases similar to “… 90% of developers have already migrated to Git …”. However, as recently as 2018, literature also indicates that SVN is still used because its users value its strengths over Git.
So say your organization has a business need to switch from SVN to Git. This might be because your organization has distributed development teams, or maybe the usage of SVN negatively impacts attracting new developers who expect a distributed version control tool such as Git or Mercurial.
Bottom line: you need to adopt Git and also migrate some or all of the information contained in SVN to Git; this blog assumes this means a codebase.
To better understand the implications of migration - I suggest Stefan Holm Olsen’s explanation. Stefan led the migration of an 11-year-old SVN, commercial grade codebase to a new Git codebase. All while continuing active development.
Atlassian documents a simpler case of a single SVN subfolder being migrated to a new Git repository This may be sufficient for some do-it-yourself organizations.
In either case, it helps that the migration team understands how Git works and also the differences between Git and SVN. Most software engineers and developers are already familiar with Git - hence the examples address the potential SVN knowledge gap.
Stefan described a 5-step general process. The following 7-step process results from adding a preliminary step, because similar to Agile, the human aspect is primordial. Having an internal champion or two will certainly help increase the odds of a successful migration. An intermediate Git repo step is also added, although the brave may choose to go directly to the final destination. Like any undertaking, communications and scheduling are critical.
1. Plan your migration including the often-overlooked human considerations:
-
- What can remain in SVN? What can / can’t be lost?
- Understand the impact of releasing notes and governance
- Identify the impact on your CI/CD environment
- Determine the timing of the actual migration (weekend, overnight, etc)
- Train users on how to effectively employ Git
- The comms plan: who’s communicating, how, and the regularity of the updates
2. Identify users and their correct names pre and post-migration
3. Choose a location for your Git repository
4. Prune the SVN codebase
-
- Address multiple folders in SVN repositories
- Complete thoughtful pruning of folders, files, old and unneeded branches
5. Create an intermediate repository to support the migration
6. Migrate from SVN to the intermediate Git repo
7. Migrate from the intermediate Git repo to the target production repo
Migrating from SVN to Git should not be feared. There are known processes when migrating from source code systems. Some planning and a lot of communication will go a long way toward a successful migration. If you need an expert hand in planning and executing your migration, contact us, we would love to help!
