When was source control invented?

Question

I'm aware of many version control systems: CVS, SVN, TFS etc...

I've googled for the very first "revision control/version control system" and seen various conflicting answers.

When was source control invented? Who invented it? What was it called?

• AakashM: Starter for 10: SCCS "was originally developed ... in 1972"
• Reactgular: It was actually invented multiple times, but they kept losing the source code.
• Ross Patterson: It depends on how you define "source control", but IBM's IEBUPDTE dates back to 1962, and it was arguably the earliest VCS.
• mouviciel: If versioning file systems can be assimilated to revision control, this dates back to the 1960's.
• John R. Strohm: @RossPatterson, that comment really needs to be an answer.

Answer 1

Here is a pretty decent timeline of the major players in video form (no sound).

It suggests that SCCS was first, by a margin of about 9 years.

https://i.sstatic.net/wcAWD.png

There is a lot missing off there though, as evidenced by this blog and the resulting comments.

• Martijn Pieters: The original paper on SCCS mentions no other systems, and seems to indicate that it had to come up with terminology itself. From that source alone it looks as if there was no version control system before 1972/73.
• Ingo: Naming a source code control system "Source Code Control System" is indeed indication that it was the first instance of something that would become a software category later.
• Ross Patterson: @MartijnPieters Rochkind acknowledges Brown's CLEAR at the end of the paper, and simply put, building SCCS on OS/MVT, he could not have been unaware of IEBUPDTE.
• Martijn Pieters: @RossPatterson: neither CLEAR nor IEBUPDTE are source control systems. CLEAR is credited for the idea of deltas, it explicitly states in the paper that there are no other similarities.

Answer 2

In 1981, I worked a summer job at Charter Information in Austin TX. They were formerly Commercial Information Corporation of Woburn MA. They ran a Xerox Sigma 6 that had been field-upgraded to a Sigma 7. They used a thing called SPUD (Source Program Update) for source code control. It was tape-based.

I routinely mounted the "bicentennial SPUD tape" and worked on a mod deck for a piece of code on that tape. It was called the "bicentennial SPUD tape" because it was written in 1976. They had older tapes, indicating that SPUD went back farther than 1976.

While a student at UT Austin (1973-1981), I ran up against MODIFY and UPDATE, two source code control programs from Control Data Corporation for the CDC 6600 and later mainframes. I do not know when they first came out, but I suspect they came out not long after the 6600, which (if memory serves me) came out in the late 1960s.

I suspect that IBM had something well before anyone else did, but I have no knowledge whatsoever of IBM mainframe history, and I like it that way.

• Martijn Pieters: The CDC MODIFY and UPDATE commands were utilities to apply software updates, not for managing changes in your own software, as far as I can make out. See apps.dtic.mil/dtic/tr/fulltext/u2/a208003.pdf, which describes the utilities on page the page numbered 52 (61 in the PDF), and computinghistory.org.uk/downloads/39256, which describes the software release materials on #4 (PDF #16) as coming in UPDATE format.
• Martijn Pieters: I believe that Xerox SPUDS (Source Program Update Disk System) was a similar package.

Answer 3

The IEBUPDTE program, originally created for IBM's OS/360 system, dates back to 1962, 10 years older than SCCS. Its purpose is to apply a set of changes to a set of input source programs, creating a set of modified source programs. All source code was managed either as "decks" of 80-column punched cards, or as files that resembled them. These source program decks had "sequence numbers" in a fixed set of columns on each line or card (COBOL specified them to be at the left, in columns 1-6, almost everything else assumed them to be at the right in columns 73-80). Sequence numbers had to increase line by line, but most source code increased by 10s, 100s, or 1000s, to allow room in the integral number space between two lines for later insertions.

A typical IEBUPDTE control deck might look like:

./ CHANGE NAME=PROG001
 PROGRAM XYZZY 00005000
./ DELETE SEQ1=9000,SEQ2=15000
 DO I=1,10 00026000
./ CHANGE NAME=PROG002
 J=256 00092000
./ ENDUP

which would modify two source files, "PROG001" and "PROG002", replacing line number "5000" (often the 5th line, following the "number by thousands" practice) and deleting lines 9000 through 15000 in PROG001 and replacing line 92000 in PROG002.

At its simplest level, that's a definition of Source Control. Unix folks would recognize that as what patch does, but using explicit numbering instead of implicit. It was common to apply sets of control decks to an input program in sequence, and to store those sets as a cohesive disk file (a Partitioned Dataset), which bears a strong similarity to the change histories that CVS and RCS store in their ,v files. IBM would frequently deliver code patches called Program Temporary Fixes (PTFs) in the form of large control decks that modified files as part of a single related changeset, which Subversion and Git users would find familiar.

• Martijn Pieters: Isn't IEBUDTE a software update system? It's similar to patch, so at best a component of a version control system. There is no graph of changes through time, as far as I can make out.
• Ross Patterson: Yup, IEBUPDTE is similar to patch.