Kiedy wymyślono kontrolę źródła?

Jestem świadomy wielu systemów kontroli wersji: CVS, SVN, TFS itp ...

Poszukałem pierwszego „systemu kontroli wersji / kontroli wersji” i widziałem różne sprzeczne odpowiedzi.

Kiedy wymyślono kontrolę źródła? Kto to wymyślił? Jak to się nazywało?

Oto całkiem przyzwoita oś czasu głównych graczy w formie wideo (bez dźwięku).

Sugeruje to, że SCCS był pierwszy, z marginesem około 9 lat.

Wiele tam brakuje, o czym świadczy ten blog i wynikające z niego komentarze.

W 1981 roku pracowałem w letniej pracy w Charter Information w Austin w Teksasie. Byli to poprzednio Commercial Information Corporation of Woburn MA. Prowadzili Xerox Sigma 6, który został uaktualniony do wersji Sigma 7. Używali czegoś o nazwie SPUD (Source Program Update) do kontroli kodu źródłowego. Oparty był na taśmie.

Rutynowo montowałem „dwusetną taśmę SPUD” i pracowałem na pokładzie modów, aby uzyskać kawałek kodu na tej taśmie. Nazywano ją „dwusetletnią taśmą SPUD”, ponieważ została napisana w 1976 roku. Mieli starsze taśmy, co wskazuje, że SPUD cofnął się dalej niż w 1976 roku.

Będąc studentem UT Austin (1973–1981), spotkałem się z MODIFY i UPDATE, dwoma programami kontroli kodu źródłowego od Control Data Corporation dla CDC 6600 i późniejszych komputerów mainframe. Nie wiem, kiedy pojawiły się po raz pierwszy, ale podejrzewam, że pojawiły się niedługo po 6600, które (jeśli pamięć mi służy) pojawiło się pod koniec lat sześćdziesiątych.

Podejrzewam, że IBM miał coś znacznie wcześniej niż ktokolwiek inny, ale nie mam żadnej wiedzy o historii komputerów mainframe IBM i tak mi się podoba.

Program IEBUPDTE , pierwotnie stworzony dla systemu IBM OS / 360, pochodzi z 1962 roku, o 10 lat starszy od SCCS . Jego celem jest zastosowanie zestawu zmian do zestawu programów źródłowych, tworząc zestaw zmodyfikowanych programów źródłowych. Cały kod źródłowy był zarządzany jako „talia” 80-kolumnowych kart perforowanych lub jako pliki, które były do ​​nich podobne. Te pokłady programów źródłowych miały „numery sekwencji” w ustalonym zestawie kolumn na każdej linii lub karcie ( COBOLokreślił je po lewej stronie, w kolumnach 1-6, prawie wszystko inne zakładało, że są po prawej stronie w kolumnach 73-80). Numery sekwencji musiały zwiększać się linia po linii, ale większość kodu źródłowego zwiększana o 10s, 100s lub 1000s, aby umożliwić miejsce w integralnej przestrzeni liczbowej między dwoma wierszami do późniejszego wstawienia.

Typowy pulpit sterujący IEBUPDTE może wyglądać następująco:

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

który zmodyfikowałby dwa pliki źródłowe „PROG001” i „PROG002”, zastępując numer wiersza „5000” (często piątą linię, zgodnie z praktyką „liczba przez tysiące”) i usuwając wiersze od 9000 do 15000 w PROG001 i zastępując wiersz 92000 w PROG002 .

Na najprostszym poziomie jest to definicja kontroli źródła. Ludzie uniksowi rozpoznają to, co robi łatka , ale używając jawnej numeracji zamiast niejawnej. Powszechnie stosowano sekwencje zestawów kontrolnych w programie wejściowym po kolei i zapisywano je jako spójny plik dyskowy ( partycjonowany zestaw danych ), który wykazuje silne podobieństwo do historii zmian, które CVS i RCS przechowują w swoich ,vplikach. IBM często dostarczał łaty o nazwie Program Temporary Fixes (PTF) w postaci dużych pulpitów sterujących, które modyfikowały pliki w ramach jednego powiązanego zestawu zmian, który użytkownicy Subversion i Git znają.