Super Brief Notes on Early Source Control Systems at Microsoft

I wrote this because my friend Laura did some tweets on “SCM” [Source Control Manager, “scum”] and it turned into a little bit of history of the late 80s and early/mid 90s.

Near as I can tell SCM went nowhere. I learned what I did about it from a series of demos that we were given back when I worked in languages at MS. It was totally unlike SLM (“Slime”, or for SLM 1.5, “Slime and a half”). Let me say a few things about SLM first.

• SLM works with just files, so you can stand up a repo in a few seconds flat.
• Everything is done with file locking
• There are two-phase commit strategies that basically involve having a script file that needs to successfully complete so most problems could be fixed with “sadmin runscript”
• Its design point was maybe a few hundred files for a dozen or so developers and it was scaled so far beyond its design point as to be ludicrous
• Later a repo “cookie” layer was added on top of SLM to allow for coordinated operations between repos, something SLM doesn’t support at all — this was done to keep the repo sizes manageable
• SLM keeps only the current checked out files locally, the masters are always on the server, as a consequence you can easily work offline and you can retroactively check out files (e.g. “out -b” –meaning “pretend I checked out this file right after I last synced it”)
• The information about what version you have is on the server, so it tracks everyone’s sync state

SCM was intended to eliminate some of the weaknesses of SLM

• No more “sadmin runscript” because SQL stores everything and you get transactions and ACID by default
• SLM has no branching, SCM had full branching support
• No particular file share mappings required, you just need a suitable connection string — migrating people can be much simpler, one redirect fixes them all
• Many operations can be concurrent because SQL (nothing is concurrent in SLM, it had to run on DOS, and DOS file servers)

Unfortunately:

• SQL Server was dog slow at the time and the SCM client was never especially well tuned for SQL queries
• In practice isolation is a problem if you aren’t super careful about how you design you schema and the unit of work, hence SCM had deadlocks and retries and so forth which made everything hella worse
• Provisioning SQL was not easy — it’s still not that easy — so the days of “I can have a new repo in 10s” were gone

All of this was far too much and so it never took off.

Perforce was adopted and customized as “SD” before SCM could ever do anything and then we bought Visual Source Safe. VSS BTW is not in any way the gold standard of source control. Alas nobody would attempt to do anything like “git” for maybe another decade. Perhaps it would take that long for file systems to be robust enough that you could actually make something like “git” and it would work on Windows.