Migrating from Perforce to Git

*This blog was originally published by GitKraken and can be found here.

Source control, aka version control, is the method of tracking and managing changes to software code. Source Control Management (SCM) systems offer a running history of code changes and can be particularly helpful for teams of developers making changes to the same files.

As a critical aspect of responsible software development, source control helps developers track code changes, see a complete revision history, and revert back to a previous version of a project if needed. Plus, version control makes it much easier to collaborate.

But not all SCMs are alike; they come with their own set of related benefits and restrictions. It shouldn’t surprise you to learn that the team at GitKraken is full of Git-obsessed developers and thus we advocate for Git, an open-source distributed version control system (VCS).

We’ve previously written about migrating from SVN to Git, and now we’re taking on Perforce, a centralized VCS commonly popular with game developers and massive corporations.

Git vs Perforce Comparison

Perforce was released in 1995 by Christopher Seiwald, former CEO of Perforce Software Company. Coming onto the scene a full decade later in 2005 was Git, created by Linus Torvalds, the father of Linux. While both systems were introduced to accomplish the mammoth task of tracking code changes, significant differences in structure and functionality are apparent.

There are fundamental differences between how Perforce and Git handle software projects. A Perforce repository can hold tens of hundreds of individual software projects, each with a distinct branching model, while Git repositories hold single software projects.

Reasons to Migrate Perforce to Git

There are numerous reasons why an individual or team of developers would seek to convert their version control system away from Perforce to Git.

First and foremost, Git does a better job of tracking code changes, the main intention of an SCM. Git’s approach is more useful because it tracks the content within the files and not just the files themselves, more accurately reflecting the actual changes in the code.

Speed

Perforce requires a connection to a server to see your history of code changes. Not only does this slow things down, the severity gets worse with each new developer attempting to access the server, causing severe bottlenecking and delay to deploying your software projects.

With Git, by comparison, you can access an entire project history in seconds. In a Git environment, each developer has a copy of the code base on their local machines. This removes the requirement of connecting to a centralized code base during your workflow.

Workflow Flexibility

Git’s more flexible permission system allows for far greater workflow possibilities for your team. In Perforce, for example, you might have restricted branch creation, making it a requirement for developers to ask permission every time they want to create a task branch.

In Git, you could just restrict push access to a master branch, so developers only need to get permission when they’re ready to implement their code into the project, not every time they sit down at their computer.

Branching

In Perforce, developers are required to create branch mapping, a task not required in Git. Not only does this require dev time and effort, which could be spent doing other things, it also disrupts an otherwise productive workflow and creates unneeded data.

Branching in Perforce creates a staggering amount of metadata; this can lead to performance problems for larger deployments. With Git, by comparison, you can have 100 working branches, but only have one branch that actually exists in your project taking up space. And, if you wanted to work on two versions simultaneously to compare results, you can clone the branch, perform some code changes, and then delete the clone without losing anything.

Learn more about Git branches and how branching works in GitKraken.

At the end of the day, Perforce branches aren’t convenient for the type of workflows most developers prefer, and ultimately won’t produce the results managers and product owners expect.

Merging & Resolving Conflicts

Perforce’s merge algorithm is unduly overcomplicated, while the result of a merge in Git is actually a new commit, containing all ancestral data.

Many Perforce users gripe about the accuracy of the tool’s built-in auto resolve feature, claiming “there have been reported occasions where work has been destroyed.” Git does an excellent job with merge conflicts. When you are prompted about a conflict in Git, a conflict actually exists, and the rest of the time, Git is resolving conflicts, correcting and saving exorbitant amounts of time.

Git opens up the possibilities for a variety of new workflows like Gitflow, task branching, forked repositories, and so much more. The adventure awaits!

Collaboration

Fundamentally, as source control management tools, both Git and Perforce are based on collaboration. Their function is to allow a team of developers to work on a shared set of files. Collaboration is a point where Git truly blows Perforce out of the digital waters.

In Perforce, you can share files between teams, but the receiving team would then have to separate the relevant code changes they want to implement into their project using a manual process. Breaking up a file submission is impossible in Perforce.

In Git, on the other hand, a team could cherry-pick another team’s changes and separate out the code changes they want to keep, without having to worry about introducing unwanted code or partially implemented features.

Perforce’s data model thinks of software history as being unique to a single server, while Git has the ability to clone and share history anywhere. This makes it possible to collaborate across company boundaries with Git, an increasingly common requirement for cross-functional development environments.

Team Onboarding

To put it simply, everybody’s doing it. According to the 2019 Coding Sans State of Software Development report, 90% of devs using version control choose Git. If you’re a hiring manager, you can assume that any engineers who learned their trade in the past five-ten years not only already know how to use Git, but will want to use Git.

Git comes with the passion and agility of the open source community, and is rapidly evolving to solve real-world problems (like the introduction of Git LFS for large file storage). Furthermore, any developer can contribute code to the project to improve a feature or fix a bug.

Learn more about Git LFS and how GitKraken supports large file storage.

Cost

This point will be quick. Git is free. Like completely free, all the time, no matter how many people are working on a project or how much data your Git repos contain.

By stark comparison, Perforce reportedly costs several hundred dollars per user, with a recent estimate of $800. Perforce no longer publishes pricing…that should say enough right there. The cost gets even more expensive for larger teams when necessary hardware purchases come into play.

Performing a Perforce to Git Migration

Now that we’ve outlined our, extremely convincing, argument for converting your Perforce system to Git, let’s get into the meat and potatoes of how to accomplish this task.

1. Prepare for the Change

Before you start shooting from the hip, take some time to communicate the upcoming changes to your team, and set up a structure for working through the transition.

Remember, switching tools is as much about the developers as it is about the data. You will want to be meticulous and have procedures for safely exporting and storing data, and you don’t want to pause every project your team is working on.

PRO TIP: Consider migrating team by team and project by project, and try to time the transition at the start of a new project.

Invest time and energy in communicating the Perforce to Git migration to your team, including the why, how, and intended end result. After all, no one likes change. You’re sure to get some pushback; find Git champions in your organization who can advocate to colleagues and keep spirits up.

It will take time for everyone to get acclimated to a new system and workflows, but it will be beyond worth it. Making small, iterative, tangible, and easy to understand changes will help the process succeed and sustain.

2. Clean Up Your Data

This is the time to delete any gratuitous branches; cutting down to one master branch per project is ideal. This would also be a good time to check for and delete any unnecessarily committed binary files.

Be particularly careful about how you choose to export binary files, as they are managed very differently in Git. While Perforce arguably excels in binary file management, this is one point where Git pales in comparison. In short, you won’t want to merge numerous large binary blobs from Perforce into Git, so clean up your data accordingly. Git LFS can come in handy here.

3. Export Your Data

There are two main approaches to moving your data from Perforce to Git. You can either employ a tool like Git Fusion, which preserves the entire history and extracts a section of your Perforce server into a Git repository. This option requires the most time and effort, but it preserves the most history.

Alternatively, you could elect to start fresh. Just extract the head of each branch that corresponds to a relevant project and check it into a new, empty Git repository. While this is the easiest, most straightforward approach, you will want to keep an old Perforce server intact in the event you need to dig into historical code.

PRO TIP: You must first ensure that your Perforce workspaces have been defined with the correct view of the data you want.

4. Get Organized in Git

After you have successfully moved your data, you can start mapping users and permissions to your Git hosting service one project at a time.

However, translating Perforce permissions into equivalent permissions for Git hosting services—GitHub, Bitbucket, GitLab, Azure DevOps—can be tricky. This is because Perforce permissions are notoriously granular and complex, with the risk of excluding access to individual files.

Perforce’s complicated permission scheme is the #1 reason a server can get bogged down; each attempt to access the server results in expensive computations on a complicated data structure.

Task your project leads to define more simple sets of permissions considering the Git structure: project, repo, and branch-level. And bask in the glory of your numerous new workflow options.

5. Sanity Check

Before you do a harsh evaluation of whether the migration has succeeded, it’s important to set realistic expectations.  For example, it’s extremely unlikely that your data transfer will result in a bit-by-bit history in Git. And that’s OK.

After you complete the data export and import, start testing. Use CI/CD verification to ensure all tests pass after you switch your DevOps pipeline from Perforce to Git. Are you still able to deploy?

What’s Next?

What comes next, after you put the blood, sweat, and tears into performing a Perforce to Git migration? Well, you can take the money you were spending on Perforce and throw a Git party!

For help getting your team onboarded using Git, checkout our Learning Git database, stocked full with Git tutorials for every experience level.

For help scaling Git within your organization, visit our Git Knowledge Center for information on successfully scaling Git with your hosting service: GitHub, GitLab, Bitbucket, and Azure DevOps.