Was the term "master" in source code management systems first used with the sense of master/replica or master/slave?

Question

In recent years there has been a push by some to move away from using the term "master" in source code management systems, often by renaming the "master" branch to a "main" branch. This is part of a broader shift away from using "master/slave" terminology in software.

But it is often claimed that the "master" branch was never intended in a "master/slave" sense, but instead in a "master/replica" sense, like that of a master record. This certainly makes sense to me: I've never heard anyone talk about "slave" branches because they're not controlled by the "master" branch (unlike a "master/slave" server system), but an authoritative "master" branch you copy from in order to tinker with does make sense for how branches are used in SCMs. However I'm yet to see clear historical evidence that proves it.

So historically, in the context of source code management systems, what evidence is there that the earliest uses of "master" branches referred to either the master/replica or master/slave metaphor?

(Can we please stick to this historical question, and not rehash the present renaming debate here.)

Answer 1

(This is essentially based on research done by Bastien Nocera. Simon Kissane’s answer includes more thorough research which revealed other uses earlier on.)

As far as I’m aware, the first SCM to use the term “master” was BitKeeper, and it used that in “master/slave” terminology:

We are then going to modify the file on both the master and slave repository and then merge the work.

This documentation dates back to 2001.

Branches are implemented as repositories in BitKeeper, so this effectively also applies to branches. The term “master” applied explicitly to branches first appears in this commit to Git; it seems likely that the terminology was inherited from BitKeeper, since Git was created following a BitKeeper license change.

Older VCSes (such as SCCS and CVS) and Subversion use “trunk”.

Answer 2

I think your question is based on a false premise that this terminology is unique to source code management. The term "slave" has been used in many computer applications to refer to replicas, not only to devices that are "controlled" by the master.

For example, the BIND DNS software has been using the terms "master" and "slave" in its configuration files for as long as I can remember (the first release was in the early 80's [Wikipedia]). Outside the config files it's common to refer to "primary" and "secondary" servers, but this was often confusing because these terms were also frequently used to refer to the order of servers queried by a resolver.

MySQL refers to their database replication mechanism as "master-slave".

I believe that the metaphor doesn't refer to the master controlling the actions of the slave, but being in control of the data that they share.

So distributed source code control systems simply adopted terminlogy that had been use similarly for many years, and used it in the common "master/replica" sense.

Answer 3

The term "master" has been used by version control systems, going back decades–the earliest I have traced it to is 1969, and uses predating that may await discovery. Git's use of "master" is only original in applying it to a branch, as opposed to a repository or file. In the vast majority of these cases, the term "master" was used in the sense of "master copy", meaning "authoritative source in case of disagreement" or "gold master", as in "copy the others are made from". (Thanks to @ssokolow for suggesting this wording.)

BitKeeper actually stands out as unusual in using the term "slave" in conjunction with "master"; I'm not aware of any other notable version control systems which did that. There is a long history of the use of the term "master" in version control systems prior to BitKeeper, and those uses did not associate it with the term "slave".

Digital Vesta (1993–)

Digital's Vesta software configuration management system (essentially a version control system combined with a build tool) used the term "master" for its master repository and "local" for its replicas, as early as 1993 (see Sheng-Yang Chiu, Roy Levin, "The Vesta Repository: A File System Extension for Software Development", Technical Report 106, Digital Systems Research Center, 1993, page 14, PDF page 20). Like BitKeeper and unlike Git, the "master" was a repository which could contain multiple branches, rather than any particular branch within it.

So, this is an example of "master" being used in a version control system, prior to either Git or BitKeeper, and in a similar sense to which BitKeeper used the term, but (unlike BitKeeper) with the correlative term being "local replica" not "slave". That said, I'm not aware of any direct influence of Vesta on either BitKeeper or Git; I don't know whether McVoy or Torvalds were aware of it or influenced by it.

CVS (1991–)

The source code and documentation of CVS 1.3 (circa 1992) repeatedly use the term "master", not to refer to a branch, but rather to the CVS repository. For example, step 6 of the INSTALL is "Setup the master source repository". An example of use of the term in the source code is in the file src/cvs.h:

/*
 * If the beginning of the Repository matches the following string, strip it
 * so that the output to the logfile does not contain a full pathname.
 * 
 * If the CVSROOT environment variable is set, it overrides this define.
 */
#define REPOS_STRIP "/master/"

(And the above define is still there in the latest version.) Note the CVS 1.3 source and documentation never use the term "slave" or "replica". The same term "master" is also used in cvshelp.man dated 17 March 1991. The earliest release of CVS I can find is from 1986, which does not use the term "master', implying its use in CVS was introduced at some point in between 1986 and 1991.

Torvalds definitely was aware of CVS and had tried it, and it did influence the design of Git – albeit mainly as an example of what not to do, as in his joking riff off What Would Jesus Do (WWJD), What Would CVS Not Do (WWCVSND); but whether CVS' influence contributed to Git's use of the term "master" is a question I cannot answer.

TRW Software Productivity System (SPS, 1982)

A paper presented at the 1982 ICSE conference describes TRW's Software Productivity System (SPS), an integrated software engineering environment designed in response to the US Department of Defense's Ada STONEMAN requirements. SPS ran under UNIX on VAX 11/780s.

Central to SPS was a "master database", which was based on SCCS for storage of file versions, and an Ingres relational database to store metadata about the files and their relations to other entities (such as requirements traceability and test plans). There is no correlative term (such as "local" or "slave") for what is not the "master".

Bell Labs Software Manufacturing Facility (SMF; circa 1980)

This combined Make and SCCS into a software configuration management system. In SMF, a particular version of a software component was defined by an "slist", which was a mapping from file names to SCCS version numbers; one slist could include another; each software system was represented by a "master slist"; SMF would ensure that the master slist was consistent, i.e. that every file included in it (whether directly or indirectly) had the same SCCS version number each time it occurred. There does not appear to have been a correlative term such as "local" or "slave". Source: Eugene Cristofor, T.A. Wendt, and B.C. Wonsiewicz, "Source Control + Tools = Stable Systems," Proceedings of the Fourth Computer Software and Applications Conference, pp. 527-532, October 29-31, 1980. Cited in Eric Schmidt, "Controlling Large Software Development In a Distributed Environment", Technical Report CSL-82-7, XEROX PARC, 1982, see pages 9-10 (PDF pages 18-19). (Yes, that Eric Schmidt, the former CEO of Google.)

SofTech Microprocessor Software Engineering Facility (MSEF; 1979–?)

A paper presented at the 1979 ISCE conference describes SofTech Inc's Microprocessor Software Engineering Facility (MSEF), which is a software configuration management system running under PDP-11 Unix, written in C, incorporating version control, and designed for developing software for Intel 8080/8085. The paper mentions that at the time of writing they were storing each version at a separate file, but had become aware of delta-based storage due to SCCS, and were planning to implement it in the product.

MSEF is based on a Software Engineering Data Base (SEDB), the central data structure of which is Software Configuration Trees (SCT). As the paper explains (page 390, PDF page 5, my emphasis):

Each software product is represented by one or more Master SCT's under the control of a project administrator. Individual programmers make logical copies of master SCT's. These local SCT's are used to develop changes. When a change or addition is complete, the administrator copies the modifications back to a master SCT. This formalizes the process of system integration and provides the mechanism to stabilize the master configuration.

It is interesting to note that the correlative of the term "master" is "local" rather than "slave". The word "slave" does not appear anywhere in the paper.

SCCS (1973–)

An SCCS file is sometimes called an "SCCS master" or an "SCCS master file". It is referred to as such in the documentation for GNU patch, Solaris patch and Sun TeamWare, among other places. While that terminology is not universal (some descriptions of SCCS do not use the term "master"), neither is it recent – the phrase "SCCS master copy" is used in Alan Glasser's 1978 paper on SCCS, "The evolution of a Source Code Control System". The manual of GNU Emacs 18.59 (October 1992) refers to both SCCS and RCS files as "master files". Emacs 18.59 never uses the term "slave" in the context of version control (although its pseudoterminal code does refer to "slave pty").

The Librarian (1969–)

Applied Data Research (ADR) developed "The Librarian" as a version control system for IBM mainframes, starting circa 1969. It stored the version controlled program in "master files". An article in the January 1970 issue of Datamation (see page 174, PDF page 176) recounts the 13 Nov 1969 incident in which a light plane crashed into ADR's headquarters in Princeton New Jersey, causing the building to catch fire. ADR staff managed to save from the fire the magnetic tapes containing the "Librarian master file"; the article points out that the data on the tape was the equivalent of over 250,000 punched cards; if ADR had stored the master copy of its source code on punched cards (as was still common at the time), it would likely have been lost in the fire, since it would have been too large to physically remove. The article ends with the remark that "ADR may have snatched a promotional victory from the flames. It's fortunate they used their own products"; and, true to the remark, ADR ran advertisements in subsequent issues that year referencing the incident.

Originally Librarian was shipped as part of ADR's Autoflow product (an automated flowcharting package), but by 1971 was being sold independently. Computer Associates bought ADR in 1988, at which point the product was renamed CA-Librarian; in 2018, CA was bought by Broadcom, who have since renamed the product to just "Librarian". The term "master file" is still used in the current Librarian documentation.

Panvalet (1969–)

The main competitor to The Librarian in the IBM mainframe version control market was Pansophic Systems' Panvalet. Although Panvalet and Librarian were once fierce competitors, they ended up both being owned by Computer Associates – CA followed up its 1988 purchase of ADR by purchasing Pansophic in 1991. Hence, both Panvalet and Librarian survive today as part of Broadcom's mainframe software product line.

And, just like Librarian, Panvalet used the term "master file" to refer to the files containing the version controlled data. For example, see this 1987 manual for Serena Consulting's COMPAREX (later acquired by Micro Focus, who in 2023 were acquired by OpenText). Rather unusually, this copy of the manual appears to come from the evidence of the infamous INSLAW case. Page 65 of that manual says:

Now "ISPF Panel CPXOPDSl" on page 59 will again be presented requesting you to fill in a dataset name for SYSUT1. We will fill in the name of the PANVALET master file like this:

OTHER PARTITIONED OR SEQUENTIAL DATASET:
   DATASET NAME  ===> 'sys2.panvalet.master'
   VOLUME SERIAL ===> ________ (If Not Cataloged)
   UNIT          ===> ________ (If Not Cataloged)

TYPE OF DATASET  ===> 1        (COMPAREX Interface Only)
 1 - PANVALET  2 - LIBRARIAN/GEM  3 - OTHER LIBRARY/DBMS

Answer 4

RCS (Revision Control System) is open source, dating from 1982 (yes, it is still around). I is a system targeted at revision control of single files, but even so it was used to manage collections of files. It called this the trunk.

Another early system is SCCS (Source Code Control System) from 1973 (part of Unix, long a closed product; yes, it is still around). It seems not to have named branches, just numbers them.