Microsoft Visual SourceSafe

» see microsoft.com/ssafe as it lived, on the wayback machine

~ the obit ~

SourceSafe came to Microsoft from outside. A company called One Tree Software wrote it, Microsoft bought One Tree in 1994, and Visual SourceSafe 3.1 went out on 14 February 1995 with the Microsoft name on the box. After that it came with the developer tools, which meant that if your shop bought Visual Studio you already owned version control and had no reason to shop around.

The release list is short and it stops early. Version 4.0 in September 1995, 5.0 in October 1996, then 6.0 on 3 June 1998, which is the one most people actually used and kept using for the next decade. A 6.0c build appeared in 2001. Visual SourceSafe 2005 shipped in October of that year and reached customers in January 2006, and that was the last version anybody ever wrote.

This product lived in a specific place: a company with a Windows network and a shared drive on it, where somebody in IT owned the backup schedule. That is not a university lab in Ankara and it is not a home machine on a TTNet line. Version control arrived in my part of the world later and through a different door, after the tools had stopped assuming everyone was on the same office LAN. By the time it was a thing I had to have an opinion about, the argument was between Subversion and git and nobody was defending this.

~ the rap sheet ~

~ the share that pretended to be a server ~

There was no server process. None. The repository was a folder of files sitting on a network share, and the client on each developer's desktop opened those files and wrote into them directly over SMB. Locking was cooperative, meaning it worked as long as every participant behaved. If the machine hosting the share dropped mid-write, or a client died with a record half-updated, the damage landed on the database rather than on one person's checkout.

Microsoft shipped a repair tool called Analyze that walked the repository looking for exactly this and tried to stitch it back together. Running Analyze on a schedule was ordinary practice, which tells you how routine the corruption was. The official guidance suggested keeping a database under a few gigabytes and well under two dozen concurrent users. Plenty of teams were past both numbers before anyone went looking for the guidance.

~ the nickname ~

Developers called it the Source Destruction System. The joke was already worn out by 2003 and people were still making it in 2012, which is a long service life for a joke about a product you had paid for. Every team that ran it had the same story: a morning spent rebuilding a branch out of somebody's local working folder because the shared database would not open.

~ the next chapter ~

Team Foundation Server arrived in 2005 with an actual server process and SQL Server underneath it. Its concurrency model no longer depended on everyone being polite to a file share. Microsoft stopped putting SourceSafe in the Visual Studio box with the 2010 release, mainstream support ended on 10 July 2012, and extended support ended on 11 July 2017. That last date is when it stopped being supported software of any description.

What outlasted the product was the habit it trained. A whole cohort learned that version control meant locking a file so nobody else could touch it, and that reflex had to be unlearned before Subversion made sense and unlearned again before git did. Distributed version control spent years arguing against the memory of this thing before it could start arguing for itself.

@}-->--

              )
             (_)
            .-'-.
            |   |
            |   |
            |   |
            |   |
          __|   |__   .-.
       .-'  |   |  `-:   :
      :     `---'     :-'
       `-._       _.-'
           '""""""

« previous  ·  random  ·  next »