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.

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

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.

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.