31

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.

  • 3
    RCS was initially released in 1982. – 5gon12eder Feb 14 '16 at 5:19
  • 1
    But how many people used it? RCS was AFAIK made for Unix and unix-like machines which didn't run on microcomputers. – 9a3eedi Feb 14 '16 at 5:47
  • 2
    We had networked systems. Just wasn't settled on tcp/ip, there were others, too like decnet. File-sharing was available in several protocols. And teams did development on minis even for micros, though some small independent developers (not on teams), just did backups instead of version using formal control. Some might emulate version control with rigorous manual backups. – Erik Eidt Feb 14 '16 at 6:44
  • 2
    We did it very carefully, mostly in wetware, because what you think of as version control didn't exist on the platforms you mention. – Blrfl Feb 14 '16 at 11:39
  • 2
    In my case, we used decks of punch cards for mini-computers in the early 1980's. Sometimes, we would save source code decks in punch card file cabinets. – Gilbert Le Blanc Feb 14 '16 at 16:40
22

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 program for Windows often had not even heard of source code control at that time.


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.

Timeline of version control history

  • 1
    when i started to work i was using VSS.. i like the welcome to hell comment. I remember getting asked by my team lead if it would be worth to change for perforce... hell yeah! – draeron Feb 19 '16 at 17:10
  • @draeron, I found the VSS was OK if you did not expect to be able to merge branches AND it was on a stable file server. One company I worked for had it on a server with bad ram chips, so kept corrupting the database! However give me perforce instead any day of the week.... – Ian Feb 19 '16 at 18:33
  • "Welcome to hell" could also apply to Clearcase... shudder – Andrew Kennan Jul 5 at 0:49
13

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.

6

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?

  • 1
    Netware was still pretty dominant until Active Directory launched with win2k. There are still lots of things Netware did well that AD can't without serious bolt-ons. – Wyatt Barnett Feb 14 '16 at 21:41
  • So what you're saying is that at the time people with microcomputers didn't use source control because they didn't need it? i.e. it was only one guy making programs in his house typically, so no need to share code or do merges? – 9a3eedi Feb 15 '16 at 4:25
  • 2
    @9a3eedi: I am painting a typical picture. People may have felt the need but it just wasn't there so you lived by your means. Merging you say? That sounds like a big complicated program. How much memory does such a beast need? What will be left for the code to be merged? I can swap floppies but if my memory is full, where do I go?! It wasn't until people had "all the memory they would ever need" (like 640K) that this was even possible. – Martin Maat Feb 15 '16 at 5:53
5

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.

  • SCCS didn't work on microcomputers. And couldn't work, because it relied on a feature purely specific to Solaris (not even generic Unix) filesystem – gnat Feb 14 '16 at 12:48
  • 1
    @gnat - are you talking about the same SCCS? I know that I used it on a Next in the mid-90s, and believe that I used it on various non-Solaris Unices in the late 80s. And the linked Wikipedia article would seem to agree that it wasn't Solaris-only. – kdgregory Feb 14 '16 at 15:31
  • 3
    Pretty sure I used SCCS on a 3B2-400 running Sys V back around 1986. ISTR that we used it instead of RCS because we were working with consultant whose company used it on their Z8000-based Xenix system and he had some makefiles that assumed it was used. – TMN Feb 15 '16 at 14:04
  • 1
    I definitely used SCCS in 1984 on Microsoft Xenix running on Motorola 68000 processors. – Charles E. Grant Feb 15 '16 at 19:12
  • 2
    It is true that Linux did not support SCCS in the 1980s. For that matter Linux support for SCCS was lacking in the 1880s, too. SCCS and other programs (e.g. rn newsreader) under 1980s Unix used open(2) to create advisory lock-files which worked if all the users obeyed the same protocol. Since SCCS was the one creating advisory locks, it could be certain to respect them. – msw Feb 17 '16 at 14:23
1

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.

1

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.

  • I would change the last sentence to 1985 :( But then I worked in finance – user151019 Feb 19 '16 at 15:00
  • @mark: I very much doubt this was true for development on PCs. Corporates mostly ignored PCs until Windows 3. – david.pfx Feb 20 '16 at 9:38
  • There was a lot of DOS programming and by 86 I was using PVCS and new joiners had Unix background but as noted it was in banking and finance so we might have been ahead – user151019 Feb 20 '16 at 18:48
  • @mark: PVCS was definitely available by 1985, but too expensive for most to use($000s). Only those moving from bigger systems and with money to burn would be using it. – david.pfx Feb 21 '16 at 23:11
-1

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.

  • 1
    The question asks specifically for information about non-unix micro systems, but the systems you describe were (at the time) only available on unix workstations. – Jules Feb 19 '16 at 14:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.