How did version control work on microcomputers of the day in the 80s and 90s?

Question

I'm curious to know how programmer teams typically managed their software development back in the 80s and early 90s. Was all the source code simply stored on one machine which everyone worked on, or was the source passed around and copied manually via floppy and merged manually, or did they actually use revision control systems over a network (CVS for example) like how we do now? Or perhaps something like an offline CVS was being used?

Nowadays everyone is dependent on source control.. it's a no-brainer. But in the 80s, computer networks weren't that easy to set up, and things like best practices were still being figured out...

I do know that in the 70s and 60s programming was pretty different so revision control was not necessary. But it's in the 80s and 90s that people started using computers for writing code, and applications started increasing in size and scope, so I am wondering how people managed all that back then.

Also, how does this differ between platforms? Say Apple vs Commodore 64 vs Amiga vs MS-DOS vs Windows vs Atari

Note: I'm mostly talking about programming on microcomputers of the day, not big UNIX machines.

Answer 1

Firstly when microcomputers first come out, the software was mostly written on Unix or VMS systems and “cross compiler/assembled” onto the target system. These computer systems were multi user often with many terminals and had source coded control systems like SCCS.

Networking was an option on microcomputers from the mid 1980s, often connected to a Unix system as the "file server" (maybe just using RS232 and Kermit to transfer the files, with SCCS on the Unix system)

See A History of Version Control by Eric Sink to get a overview of how version control system have changed over the years.

I recall reading about source code control in "BYTE" in the late 1980s, so it must have been in use on "small systems" by then.

SourceSafe was well established by the mid 90s running on Dos, Windows, etc.

This link shows an article about PVCS running on PC from 1994, it is at version 6.2 so had clearly been about for some time, Wikipedia says it dates from 1985.

---

However numbered floppy disks were used by most programmers working on small scale software until the late 1990s, to be replaced with folders on their hard disk, making a copy of the source code every day.

I remember working on a project porting software from Unit to Windows NT 3.5. Programmers that know how to write programs for Windows often had not even heard of source code control.

---

This timeline is taken from a blog post by codicesoftware, they sell Plastic SCM, however the overview of the history of other systems seems reasonable, a few older system before RCS are left of the image.

Answer 2

This is probably not representative for the games industry at large, but it worked well in our small games company. Never worked with business software, which probably had other requirements.

From the mid 80s until the mid 90s I often used a version number at the end of the file name, e.g. "game.003". Back then I was programming 90% in assembler and all the code was in a single huge file, possibly with one or two includes, where I'd manually have to update the version number as things changed. I'd only increment the number after I had a stable version that I was sure I wanted to keep.

This eventually scaled somewhat comfortably to about 3 people. After that we grew the team and ended up having a mess of files all over the place for a year or so until I got fed up with trying to track down individual people's changes and we began using Perforce around 1997-98.

Answer 3

You have to see this in the context of common infrastructures at the time. In the early 80's IBM released the "personal computer" and you can take this quite literally. The most common way to develop applications for a PC was one guy creating something and trying to sell it. So one floppy per released version would probably be common. You could buy some nice colorful labels and write the name of you product and the version on it. For most of the successful products of those days you knew the name of the guy who wrote it.

Networks were introduced as add-ons. Client API's were hacked into DOS and the server parts were dedicated, propriatary operating systems on a separate machine. Typically expensive (not for the masses) and basically just offering file and printer sharing. In the PC world things started to change with the introduction of Windows for Workgroups and Windows NT. That opened up a lot of possibilities. Networking was finally integrated in the environment a programmer was familiar with and a Windows programmer could write applications that could talk to eachother over the network. This was the end of NetWare as the dominant network operating system.

Soon several version control systems popped up with client and server components that you could easily install on any combination of machines. With plug-ins for IDE's and client components supporting command line options that enabled integration in a build system.

After the web took off and PC-access to the internet became ubiquitous, you got the open source movement and web based source control systems. The funny thing is, when the PC was introduced this was seen as a bold move from centralized computing to distributed computing. But the definition of central versus distributed has blurred. Is the cloud the ultimate distribution or is it just the new monster central computer that holds all the power, much like the IBM mainframe used to be?

Answer 4

In the 90's I definitely used software for version control. There was SCCS, and Apple's MPW had built-in version control (Projector). And I think I used Projector around 1992. At one company the version control system was a large cupboard with floppy disks of every version, taken once a week.

Answer 5

From personal experience: 1985 MS-DOS networked development PVCS was available and too expensive. For Apple and all non-MSDOS PCs: nothing. I used T-lib ($50) from 1987. Unix ports (SCCS), started filtering down around 1990, SourceSafe around 1992.

By 1995, if you weren't using a VCS you weren't serious.

Answer 6

My first summer programming job while I was still back at school (this would have been circa 91 I think) was to implement an automated version management and backup system for the small firm I was working at. We had 3 pcs hooked up to a netware server, and the owner had finally got tired of handling version conflicts and working out what needed backing up to floppies, so we made developers work on their own pc rather than directly in files stored on the server as they had until now, and I wrote a system that kept all their files set to read only until they ran a program that checked nobody else was using them, then recorded the use on a central btrieve database (a relational database with a simple query api rather than full sql which ran on the netware server). Another program checked out their modified changes and copied them to the server, and a third was run at the end of every day to copy everything changed onto a floppy.

While this system was custom built for the small firm I worked at, I imagine many similar shops had similar processes.

Answer 7

Very early nineties before we got the first version control system, we had three developers and a server containing the “master”. When I made changes, one of the other two guys had to review my changes and merge them to the master (manually), then everyone merged the master into their own code, again manually. Worked quite well.

For refactoring, two people would agree exactly what changes to make, both made the changes, then both versions had to be diff’d and changed until they were identical and then copied to the master. Worked better than unit testing. We were good, we made sets of 200 changes independently resulting in one or two differences only.

Answer 8

In 1993-1995 I was with a pension manager with 15 developers doing C/C++ development in SunOS with SPARCStation 20s and Sun IPX. Our codebase was in NFS mounted directories. Initially we were doing Copy Folder Versioning, but at some point we moved to SCCS and some teams started using RCS.

In 1995 I moved to another company with 80+ developers doing C/C++ development in New York, London, and Hong Kong. We used ClearCase with the multi-site add-on to manage the development environment.

ClearCase was good at synchronizing the code base between sites, but at the time required almost a full-time administrator to keep things running. It was also much slower because ClearCase presents files in a virtual filesystem, with a configuration specifying versions of directories and wildcarded filenames based on branches, time, and/or tags. In a pathological case, one could specify every individual file to have a different version.