About Git and Perforce..

All this started with a reading of a simple post why Java is slower that C. This is actually interesting, and controversial, question which I'm going to address in another post, but this time I ended up in reading what different developers are saying about git and perforce. It's also interesting to find out about different repositories that exists, and I mean on those that are proprietary. The source for the material in this post, apart from the mail that started it, was this blog post, and this presentation from Google. I also looked at Perforce's user conferences materials.

Perforce is code versioning system popular in many companies, i.e. Google, FreeBSD, RIM, and many others that is a proprietary product with a hefty price tag (somewhere between $740 and $900 per user per year). There are free and trial versions available, and as far as I know, clients are free. Also, I think that Perforce offers free versions of software to open source projects. In essence, Perforce is not a distributed version control system. It requires a user to have a centralized repository/machine that will host all the necessary data. Furthermore, it seems as there is no way to have some kind of a cluster to host that repository, at least not at the application level (i.e. Perforce). That was true several years ago and could be true today. Because of all this if you look at what's the main talk on Perforce User Conferece you'll quickly conclude that majority of talks are about performance and how to achieve it. It is also interesting to note that I stumbled on one presentation that claims it is better to host Perforce repository on Linux server than on Windows.

Git on the other hand is a completely free and extremely popular distributed version control system. The most known application of Git is as a repository for the Linux kernel, but it's used all over the map, both for open source projects and for closed source projects. Git is specifically aimed for revision control of source files and not binary files.

What I concluded from reading all the comments about git vs. perforce is that Perforce behaves better in case binary objects are in repository too. This is a primary use case for game development that requires all the artwork (video, audio, picture) to be attached to specific source version. Git wasn't designed to handle that use case even though there were discussions about that in 2009 (see the thread that started my inquiry in all this). But git is praised for its branching capabilities as well as some other capabilities not present in Perforce. In essence, those capabilities are the consequence of its distributed nature. For example, you can send your local changes to other developer without committing the changes to some central server. Also, Perforce allows (and forces) developers to mark the files as being edited. This makes it possible to find out who is editing which file. But it creates some problems, e.g. scalability.

One more interesting thing I learned is that Linux is actually a small project. :) This was a surprise to me, but then, after second thought it seems natural, if nothing else than for games that have to put a lot of non-programming stuff into the repository. Reported sizes of the repositories are from 6GB up to 100GB as Google claims in their presentation from 2006 (the one linked above). This is impressive, and what occurred to me is that it would be interesting to do some kind of survey of the sizes of repositories and their use cases. Anyway, it is particuarly interesting to know that Google runs largest Perforce server with over 12000 users.

While looking for information about Perforce I also found out that there is competitor called ClearCase. But, according to what I've found ClearCase is more expensive than Perforce.

For the end, I have to say this is very interesting subject that woule be interesting to do some kind of a survey. Wikipedia, as usual, has very good comparison chart of major version control systems that could be a good starting point for anyone's research into version control systems.