Fog Creek Software
Discussion Board

Software Configuration Management in Organizations

I am involved in the Subversion project ( ), that aims to create a compelling replacement to CVS, and provide a robust version control for everybody. Now, I've been to its channel on FreeNode and we
were visited by a contributor who is now a Microsoft employee. He told us some things about the state of Software Configuration Management in Microsoft.

Microsoft used to use a version control system titled SLM for their development. This was basically an SMB share with some scripts to commit and check in files. Eventually, they switched to a different ones, which scales very well and is more decent. They also use their own internal bug tracker which was not released to the public.

The Windows 2000 team used ClearCase from Rational Corp. (now part of IBM).

I told the guys there that I know a couple of people who work in Mercury Interactive and they use there their own internal version control system as well, which they started developing 10 years ago. It's written in Perl and has some features not present in CVS, but is still not something that would be worthwhile to ship to the outside, because it will be shadowed by what already exists now. Still, they have an entire team maintaining it, and they cannot switch because they have a lot of scripts that depend on its particular way of operation.

Someone else from the Subversion development team, noted that many companies have created their own ad-hoc SCM systems and spend millions of dollars internally to support them.

If you ask me, wouldn't it be more worthwhile, to write wrappers for the behaviour of the in-house version control/bug tracking/whatever system around an existing, superior open source solution, and pull efforts on maintaining and enhancing the latter instead? I suppose new businesses nowadays will not consider developing their own anymore because there's a wide variety of available tools to choose from. But what about all the existing systems?

Shlomi Fish
Sunday, September 14, 2003

It seems to me that, if the size of the organization is large enough to have considered rolling their own SCM, then the organization is probably large enough for the following to be true:

1. There's no single good time to migrate the database, and doing it in pieces may be too painful to consider;

2. The politics of the organization may preclude changing.

I would certainly never think about rolling my own. As a member of the Subversion team, my question is: why did you guys roll your own? Why didn't you extend CVS? :)

Brad Wilson (
Sunday, September 14, 2003

"Why didn't you extend CVS?"

Subversion is exactly meant to be a better CVS. However, CVS' architecture does not give way too much to allow everything that is possible in Subversion. CVS is basically a tree of RCS files, where the versioning of each file is kept separately. Thus, moving a file or directory or copying it is very hard.

Subversion, on the other hand, has reachitectured itself around a central database, that allows O(1) copying and moving of files and directories. Since a branch is basically just a copy in Subversion, it also means there's a cheaper  branching and tagging. That put aside, Subversion also supports atomic commits, inherently client/server architecture (with the ability to work over HTTP/S) and a very modular design.

Note that Subversion was not meant as a product for in-house use. It was started from the grounds-up to be shrinkwrap.

Shlomi Fish
Sunday, September 14, 2003

Shlomi's post describes the consensus among just about every CVS user and developer, except Tony Hoyle, who's now fitting a database backend to CVS, that provides O(1) branching, atomic commit, and the like, while still remaining compatible as far as clients are concerned (and, most probably, keeping a shadow old-style CVS directory for tools that access it directly).

Mind you, CVS (on the CVSNT branch) already has atomic commits and history-sensitive merging, which were considered "too hard" by almost everyone. Tony Hoyle does amazing stuff with the old CVS codebase.

For more info, see [ ]

Tony has probably rewritten 50% of CVS in the process, but this was done gradually over the past 2 years, a fine example of refactoring.

Subversion has some features that CVS will probably never be able to compete with, but it looks like CVS will address what was, at first, considered the compelling reasons to start a new version control system.

Ori Berger
Sunday, September 14, 2003

<slightly off topic>
Hell - from what I've seen, I'm just happy if a software shop actually USES configuration mgmt -- whatever the tool!  I've been shocked/surprised all too often at how few people (claiming to be software "professionals", no less) don't understand the value of CM, much less use it.  ah well, that's a different rant (see old thread I started here some months ago re understanding of and schooling in CM).  Trying to get some people to understand why they should use it is a little like explaining why water is wet...
</off topic>

Monday, September 15, 2003

The microsoft SCM is called SourceDepot and is described here

Essentially they got bit by some big scalability problems with their old system.  Not a surprise when one has thousands (tens of thousands more likely) of developers.  So they created SourceDepot.

Monday, September 15, 2003

Source Depot is _probably_ a customized version of perforce.

No one seems to know for sure, though.

Ori Berger
Monday, September 15, 2003

I actually heard from two other sources that Perforce served as the basis for Source Depot. I am glad that Microsoft at least did not write it from scratch, but I'm worried at how much it will diverge from the shrinkwrap Perforce in the future.

Shlomi Fish
Tuesday, September 16, 2003

I am a Microsoft Developer.  I can confirm that the SCM system being used internally is "sourcedepot".  I myself was not aware of sourcedepot being something developed by Perforce.  But on going through the comments on this website and cross checking the Perforce documentation it is absolutely certain that sourcedepot and Perforce share a common ancestry.

Developers are extremely unhappy about the SCM system utilized in Microsoft.  Though the idea it scales well may be true, I believe that it is more hype than the truth.  The documentation available is horrible while it is not possible to gain a high level understanding of the architecture.

In-fact I was researching Subversion and was impressed by the clarity of its documentation and most importantly it just makes sense. 

Considering the experience at Microsoft I would strong recommend against using Perforce.  Use subversion instead.

Nikita King
Thursday, February 12, 2004

In reply to what Nikita King said about Perforce: well, most people who worked with Perforce (the shrinkwrap product itself, not the in-house Microsoft derivative) seemed to like it quite a bit. It's very reliable, very fast, and also just works. The customer support is helpful and friendly. It's also very portable.

Perforce is much better than CVS. So is Subversion. Which is better: Subversion or Perforce is hard for me to judge because I did not work with Perforce. I can fully recommend Subversion, but you should not rule out Perforce, either.

Shlomi Fish
Thursday, August 5, 2004

*  Recent Topics

*  Fog Creek Home