Perforce is more than a version control, it is a legend


Perforce (P4) is one of the most successful version control systems ever created.

It was extremely big in the gaming industry and it used to be the de-facto standard for huge companies like Google and others, until they decided to pull the cord. (Legend says the internal version control used by Microsoft to develop Windows was a Perforce fork).

P4 has existed since the mid-90s. It was created before the now ancient Subversion was even launched, back in the times of CVS, SourceSafe and the incredibly expensive Clearcase.

It was more than just a tool; for many developers it was a true legend.

Is there any good alternative to Perforce?


If you are currently using Perforce and looking for an alternative, then this guide is for you.

Our goal with this guide is to help you figure out if it is better for you to stay with P4 or if you would better served by a different version control.

Disclaimer

We design and sell Plastic SCM, an alternative version control to Perforce. So, we are obviously biased.

But our goal with this guide is not to convince you about the merits of Plastic.

Over the years (we have been in business since 2005), we have moved hundreds of teams from P4 to Plastic SCM. Many of them loved the results, and some simply decided to quit and return to Perforce.

Our goal is to avoid the frustration and time loss that happens when teams move to a different version control system with the wrong expectations.

Let’s see if Plastic is right for you.

Otherwise, we’ll try to recommend to you a different alternative or to simply stay with Perforce.

Perforce strengths and weaknesses


What are the reasons to move away from Perforce?

As I said above, we have worked with lots of teams, so let’s see if any of the following points ring a bell.

  • Reason 1. You need stronger branching and merging. Perforce can branch, but not likely at the scale you need.

  • Reason 2. Your developers require a Git-like workflow, but you still need to handle big projects and big files. This is strongly related to Reason 1, since Git is well-known to be stronger than Perforce with branches and specially with merges.

  • Reason 3. You need to modernize your toolset because of different reasons. Maybe you don’t like the evolution of Perforce in recent years, or maybe there is a strong requirement in your organization to adopt different workflows.

  • Reason 4. You need to implement DevOps, shorten release cycles and focus on task cycle time.

  • Reason 5. Cloud hosting. Maybe what you require is a way to host your depots in the cloud, even if it is just to enable collaboration with other geographically distributed teams, and you’re afraid of Perforce not providing their own native hosting anymore.

But Perforce has many strengths that you can’t ignore

Perforce is a super strong system. Thus, many features are a must for teams using it. Let’s see if the following list is as relevant to you as it is for many teams we have worked with.

  • Strength 1. Locks for files you can’t merge. Not everything is code. There are assets, documents, images, videos, models and many more where collaboration requires just one contributor making changes at a time.

  • Strength 2. Simplicity for non-coders. Git might be the pervasive version control on Earth, but for many it is a problem to use. That is especially true for non-coders. Artists in game development, engineers dealing with models and many more, simply prefer to skip the "extra push" imposed by the Git model. Sometimes you simply want to work centralized.

  • Strength 3. Huge depots and big files. When your depots are several gigabytes, even terabytes, then Perforce shines where others crumble. Git has well-known struggles when repos go beyond a certain size.

  • Strength 4. Work centralized. This is related to Strength 1 but deserves a point on its own. Sometimes you just can’t afford to have a clone of the depot on each workstation because the size is too big. Or maybe because of some privacy or auditing policy or some compliance rules that you must adhere to.

  • Strength 5. Speed. With very big depots, speed matters. High data transfer speeds are deeply related to the big depots and big files requirements.

Are we on the same page?

Did the previous weakness reasons and strengths ring a bell? Did they describe what you are looking for?

If not, maybe you can share your concerns with us. Email us at support@codicesoftware.com and share your particular requirements.

Otherwise, it seems we know what you are looking for. Now it is a matter of figuring out if we can really offer you an alternative to Perforce.

Possible alternatives to Perforce


There are many version control systems out there, but if you need a solution as of 2020, the list comes down to just two options: you can switch to Git or you can migrate to Plastic.

I wouldn’t say Mercurial is not a good option, but it certainly has decayed in popularity in parallel to the huge rise of Git, mostly thanks to GitHub.

I wouldn’t consider Subversion either as an alternative to Perforce, because while SVN is free, you would be doing a step backwards in terms of functionality.

Thus, we are left with two choices: Git and Plastic.

Why you should move to Git if you are using Perforce

Git certainly won the version control wars, if there ever was one. Git is the version control system that is the most widely adopted on the planet, mostly thanks to the incredibly successful GitHub collaboration platform.

So, you should definitely go to Git unless you need any of the following missing features not found on it.

What are the Git limitations you should keep in mind when migrating away from Perforce?

  • Warning 1. Locking. Git doesn’t natively support locking. GitHub and a few other providers implement some workarounds, but it is definitely not the locking you are used to in Perforce. It is an external workaround to mark files in a way so that they are not overwritten when sent to the central server. But Git locks don’t do a great job preventing the concurrent changes in the first place, which is the key reason you need locks. Locks are there in P4 to prevent wasting contributors time by doing changes they will later discard. If you don’t need strong locking, then you are good to go with Git.

  • Warning 2. Big depots/repositories. You might certainly have heard of Microsoft implementing their own extensions to Git to support big repositories. Basically, they are trying to convert Git, a distributed system, into a centralized one. At the time of writing this, this solution is mostly used just by Microsoft internally. The other alternative is to use Git LFS (Large File Storage). LFS is a workaround to store files outside Git repos so they don’t break. Instead of storing the object inside the repo (like Perforce does) they store a reference, and then the actual object is stored elsewhere (typically in GitHub, the object is stored in some Amazon AWS blob). The solution is not native, and this is the key reason why teams with large files move away from Git, even when they are small teams. If you don’t need big files, or if your depots are not large, then you are good to go with Git.

  • Warning 3. Git forces you to work distributed. This might not be a big deal for your company (in fact it is not for thousands of teams around the world). It basically means you must have a local repository (like a local depot) on each contributor’s machine. Each of them needs to modify their workflow and do a push after they submit changes to the depot/repo.

  • Warning 4. Single-branch workflows are not well supported. The concept of distributed repositories means your contributors will always be doing a local submit before contributing to the main branch. This invalidates locking scenarios, but also complicates some trunk-based development practices.

  • Warning 5. Trouble with moves and renames. Have you ever experienced issues with renamed and moved files or directories in Perforce? Git tends to perform slightly better than P4 with this, but chances are you will still run into issues.

  • Warning 6. The edit before modify philosophy is not available. Perforce likes to enforce that they adopted a different philosophy to perform changes. In Perforce you do a p4 edit to notify the system you are going to touch files. This is strongly related to Warning 1, but it is also a way to understand development. This is simply not available in Git.

Do you care about any of these? If not, Git is probably the best choice for you.

Let’s also consider some of Git’s strengths.

  • Strength 1. Branching and merging. Git is very good with branching and merging. Creating a branch in Git is always way much faster than in Perforce. It is true that Perforce streams focused on improving branch performance, but while branch creation is a constant time in Git (it just creates a new pointer, no other logic required), it is still a much heavier operation than in Perforce. The underlying merge algorithms are also stronger in Git. This is because of the differences in "merge tracking" (more about this detail later on). While merges are tracked "per-file" in Perforce, they are "commit based" in Git. Simply put: if you need to merge a codebase of 100k files, calculating the conflicts will be fast in Git and slow in Perforce because it will have to calculate as many merge trees as files involved, while Git only checks a single tree. You might remember the old motto shared by Perforce and Subversion in the early 2000: branches are evil. Git changed that and that’s why many developers associate "distributed version control" with good branching and merging, although it is not entirely true.

  • Strength 2. True distributed development. Having local repos and being able to push/pull to others is something many developers take for granted. Git implements this natively (at the cost of not being able to work in truly centralized fashion), while Perforce struggles.

  • Strength 3. Excellent cloud hosting options. GitLab, GitHub and Bitbucket, just to mention a few, are excellent cloud repository hosting and collaboration platforms for Git. Perforce doesn’t even provide its own native cloud solution.

  • Strength 4. A rich ecosystem. Git is certainly the lingua-franca of version control. Every tool, IDE; editor, continuous integration and continuous delivery system, integrates with Git. It is possible to deploy to Azure, Amazon, Heroku and almost any system using Git. That’s certainly a huge strength.

Perforce vs Git: checking what really matters

The following tables summarize how Git scores in the reasons to move away from Perforce and how it matches the Perforce strengths.

P4 strength How Git scores

File locking

Poor

Simplicity for non-coders

Poor

Huge depots and files

Poor

Work centralized

Poor

Speed

Good if depots are not huge

Reasons to move away from P4 How Git scores

Stronger branching and merging

Good

Git-like workflow

Excellent

Modernize your toolset

Excellent

Implement DevOps

Excellent

Cloud hosting

Excellent

Git ticks all the boxes in the reasons to move away from Perforce; but doesn’t when compared to the Perforce strengths.

So, if you can completely switch to the Git mentality and the P4 strengths are no longer requirements, Git is definitely your tool of choice.

Sometimes Git is not enough

The reason why we are in business with Plastic SCM is because we try to combine the best of both worlds: the strengths of Perforce and Git.

The following table summarizes the situation and serves as a starting point to introduce Plastic.

P4 strength How Git scores How Plastic scores

File locking

Poor

Excellent

Simplicity for non-coders

Poor

Excellent

Huge depots and files

Poor

Excellent

Work centralized

Poor

Excellent

Speed

Good if depots are not huge

Excellent

Reasons to move away from P4 How Git scores How Plastic scores

Stronger branching and merging

Good

Excellent (better than Git)

Git-like workflow

Excellent

Excellent (different than Git)

Modernize your toolset

Excellent

Excellent

Implement DevOps

Excellent

Excellent

Cloud hosting

Excellent

Good

Now you might say: "oh, yeah, the typical all-greens table to show how great your product is". Well, the next pages will cover what we do better than Git, what we do worse, and when Plastic is simply different than Perforce, and you must take it into account.

Where is Plastic SCM worse than Git?

I will start with Plastic weaknesses when compared to Git, so you can have the bad news first before moving forward.

  • Weakness 1. Online information. Git has an incredibly rich community. Millions of users and an open source heritage means that anything you write in Google will return one hundred different ways to solve it. In Plastic, in contrast, you won’t find such a huge variety. Yes, we have a public forum and lots of documentation and videos, but it is certainly not on the same scale as Git. We try to solve the issue with an incredibly good support. 85% of questions are answered in less than 1 hour. 95% in less than 4 hours. Sometimes is not a matter of having tons of answers, but rather having one right answer.

  • Weakness 2. Cloud collaboration platform. GitHub, GitLab, Bitbucket and most of the other hosting alternatives are incredibly rich collaboration platforms. Our Plastic Cloud solution, in contrast, is purely a cloud server. It is like if you had a scalable Perforce server where you can host as many depots as you want and forget about any maintenance. But we don’t offer as rich of web interfaces as GitHub does. We are moving on that front, but our goal is not to compete head to head with the GitHubs/Labs/etc trying to outperform them in what they do best: web UIs. They have a legion of people working on that. Where we compete is in the core. Need a cloud hosting for repos in the gigabyte range? Then Plastic Cloud runs circles around the Gits.

  • Weakness 3. Integrations. We provide native integrations with CI systems, IDEs, issue trackers and may other tools. If what you need is in the list, then we get you covered. If not, the Git ecosystem will certainly beat us. Plastic implements the Git network protocol as a way to have a universal connector with integrations, and very often it is perfectly fine. In short: we react fast, we add more integrations when required, but it would be foolish to think our dev team alone can match the development power of all the tool makers developing their own integrations with Git themselves. Is this a deal breaker? It is not, otherwise we wouldn’t have thousands of customers, but it is worth noticing.

How is Plastic SCM stronger than Git?

From a Perforce perspective, there are several strengths to consider when comparing Plastic to Git.

  • Strength 1. File locking. Plastic SCM implements file locking natively and Git doesn’t. This alone can be a huge factor for many teams because they simply can’t work without preventing concurrent changes in unmergeable files.

  • Strength 2. Simplicity for non-coders. A software project is not just about coders. For instance, in game development, artists hate the extra push step, or being unable to just submit changes and forget, or simply select what they really want to update to their workspaces. Plastic can do all that while Git can’t.

  • Strength 3. Huge depots and files. Plastic is designed to deal with big files and big projects. It doesn’t need workarounds like Git LFS or even GVFS. It won’t break with depots in excess of 5 TB. This applies to Plastic Cloud too.

  • Strength 4. Work centralized. Plastic can work in centralized way, just like Perforce. This is a great advantage for many teams using P4 today.

  • Strength 5. Simpler branches. Branches in Git are pointers to certain commits. It is a clever design, but probably one of the things harder to grasp for newcomers. In contrast, Plastic branches are what you intuitively expect them to be: changelist containers.

    The following figure highlights the differences:

    Git vs Plastic branches

  • Strength 6. Even stronger merging. Git is good at doing merges, but Plastic is even better. Most of the reason is because Plastic handles directories as first-class citizens while Git tries to ignore them. This extra complexity pays off during merge.

    Merge case Perforce Git Plastic SCM

    Move/change

    Issues

    Issues with complex cases

    Yes

    Change/delete

    Yes

    Yes

    Yes

    Move/delete

    Issues with complex cases

    Issues with complex cases

    Yes

    Divergent move

    Yes

    Issues

    Yes

    Cycle move

    Fail

    Fail

    Yes

    Move/add

    Fail

    Issues

    Yes

    Evil twin

    Yes

    Yes

    Need 2-way version merge

  • Strength 7. Speed. Git is faster than Perforce (remember when Perforce used to be called "the fast version control system" prior to Git?). But Plastic can outperform both in basic add/submit and update operations.

    The following is a comparison of Git, Perforce and Plastic adding a small project (65k files and 700 MB). As you can see, Plastic is 8 times faster than Perforce completing both the add + submit (add + checkin in Plastic jargon). Plastic is also twice as fast as Perforce downloading the full 700 MB (sync in P4 and update in Plastic).

    Speed comparison small project

    Next, comes a comparison with a medium sized repository: 180K files and 7 GB. Again, Plastic is 5 times faster than Perforce, although network time and IO for the data tends to reduce the differences.

    Speed comparison medium project

  • Strength 8. Version directories and moves. Move one directory with 1000 files inside. Git detects 1000 moves. Plastic just one. It makes a huge difference later on when you have to diff and merge the changes.

  • Strength 9. Tools and GUIs. In Perforce, you were used to a certain GUI, provided by Perforce themselves. And also, p4merge, the extraordinary merge tool. In Git, you will have to grab different tools from different sources. That’s not bad per se, but it can be hard to achieve a consistent experience. Plastic comes with GUIs for macOS, Linux and Windows, and diff and merge tools that even understand the code. (We call it semantic technology: they parse the code before calculating diffs and merges, unlike p4merge, when you move a method, class or function so they know what’s going on).

  • Strength 10. ACL based security. Plastic provides Access Control Lists (ACL) to secure each object in the system. It comes with a set of +32 different version control specific permissions. In contrast, in Git you can typically just restrict which repos are writable or read-only, but you can’t have finer-grained control.

    The following is a screenshot of the permissions in Plastic of a given branch, showing some of the specific options. Perforce allows a finer grained control than Git, and Plastic offers an even higher degree of control.

    Security

    Read more about security.

Deciding to switch


Switching version control is an important decision. Consider carefully the Perforce strengths and ensure the ones that you’ll lose are not essential to you.

Perform a proper evaluation, test the software and ensure it really works not only in demo scenarios but in the kind of tasks the team is going to perform on a daily basis.

Write down the expectations. What’s the added value you expect from the switch? What are the pains you want to remove? Put it down on paper. It will be easier to evaluate progress down the road.

Don’t just test the software. Test the support, responsiveness and general knowledge of the version control manufacturer of choice.

If you decide to try Plastic SCM

Are you ready to switch? When you decide to go with Plastic SCM, here is the roadmap we propose:

  1. Contact us. We can help you understand if Plastic is really what you are looking for.

  2. We will analyze your depots. We will check the size and layout of your repos to determine the best migration path.

  3. Migration. We’ll help you migrate from Perforce to Plastic, at no extra cost.

  4. Training. We’ll train your team to ensure the switch is successful and you really get the value you are paying for. It can be as simple as an online session, but it is worth the time.

  5. Follow up. We excel on support and customer success. We’ll be in touch continuously, especially at the very beginning until things simply flow.