Something new in Perforce SCM

Whatever else is true in development, the importance of “version control” can’t be overestimated. You simply don’t want the bugs you’ve fixed coming back simply because someone implements a new version that isn’t aware of the changes you’ve made.

The trouble is, “version control” tends to be imposed on free-spirited developers by men in suits who can see why it is necessary but have no idea how much of a PITA using some of the products can be. I remember someone once telling me how much he hated his unproductive role as “fixer of the broken database” for one product. An expensive team member occupied just about full-time with fixing corruptions introduced by a product which couldn’t scale up to match the team’s needs!

Which rather explains the popularity of “viral marketed” version control, brought in by developers at the grass roots who fully realise that it’s needed but would rather choose something that works. And, at least with Open Source, for instance, you can see how it works—and “painful” things you do to yourself are always less painful.

Nevertheless, while Subversion, say, is both popular and effective, there is more to “Software Configuration Management” (SCM) than mere “Version Control”. Ideally, it should be part of a “Configuration Management System” and link back to the business changes which drive the development of new software versions— although perhaps that’s for another blog.

And, quite often, scalability in the widest sense is still the issue. Lots of people, in different locations, often working for different companies, and working on large software projects makes for a large, complex configuration problem—and different approaches to solving it are possible.

So, different products meet the needs of different development cultures—and neither Subversion nor Git, both excellent in their way, have 100% market share, despite the amount of media attention they excite…

Perforce is one of their competitors that still has a place in serious large-scale software development—for example, I believe that Microsoft uses a “forked” version of Perforce it acquired years ago (and has since developed) called SourceDepot, internally. This isn’t part of the publicly available Team Foundation Server, which is also used widely within Microsoft (and, allegedly, everyone there is going to migrate to TFS eventually); but SourceDepot is still used for Office and Windows version control, as Richard Erwin admitted at the CMSG Agile SCM event last year; see Perforce website.