Downsides to Git

Git is the default version control system for most people in software. It is easy to set up and simple to use:

  1. Create a code repository with a main branch (used to be called master branch).
  2. To make a change to code, make the necessary edits to code. To make a "save point" of the current code, you create a commit with the edited code files. Once you've confirmed that the code works, you push to the branch.
  3. If the change you intend to make is large (for example, adding a fancy new feature), you can also create development branches to avoid breaking your project in the main branch. If something goes massively wrong with your new feature, you can start over easily.
This system works well if you have a few people working on a small project, but unfortunately it doesn't scale well. Here are some scenarios to demonstrate:
  1. Many, many people editing code very frequently: When multiple people push edits to the same file to the same branch, merge conflicts will arise. Git provides little help with resolving merge conflicts.
    2. Most people set up remote repositories (such as on Github). If someone wants to make a small change, they must have a local copy of the entire repository. If the repository is large, this is a waste of time and space. Avoiding this is possible with Git, but messy.
  2. Git simply refuses to work with large files. This is a problem if you need to store binaries/images/logs/etc.

Perforce

Perforce has a steeper learning curve (possibly because it's harder to find a person who can help you learn it?), but it provides plenty of benefits over Git:

  1. Perforce's conflict resolution tool is fantastic. It is quite good at auto resolving, and it also gives you a diff when you need to manually resolve conflicts.
  2. Perforce branches are not the same as Git branches, and they are very sparingly used. This makes versioning a much more linear process.
  3. With Perforce, you can prepare multiple unrelated "commits" at the same time by using multiple changes within a workspace.
  4. Perforce has great integration with code review tools. This isn't technically required of a versioning control system, but it is neat to have!
  5. Since Perforce is a centralized system, it can lock a file so that no further changes to the file will be made.
  6. Perforce is excellent for storing/sharing large files. Also, since Perforce doesn't require the user to make a local copy of the entire project, this saves a lot of space.
  7. Perforce allows you to view a file in time-lapse mode, which is neat!
  8. You can see who else has checked out (is editing) a file that you are also working on.
One of the main disadvantages to Perforce is that if you need to edit the same file for multiple changes, you would need multiple workspaces. This means that you will have multiple local copies of the same file (well, different once you edit them), which might take a long time to copy over if the files are large or if there are many files.
The other disadvantage is that Perforce isn't free.


This isn't to say that we should always use Git. If you have a quick-and-dirty project to work on, Git is great. I have not tried to use SVN or Mercurial much, so I can't comment much on them.