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


20

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?



18
Został wynaleziony wiele razy, ale wciąż gubili kod źródłowy.
Reactgular

4
Zależy to od sposobu zdefiniowania „kontroli źródła”, ale IEBUPDTE IBM pochodzi z 1962 r. I prawdopodobnie był to najwcześniejszy VCS.
Ross Patterson

2
Jeśli systemy plików do kontroli wersji można przyrównać do kontroli wersji, dzieje się to w latach sześćdziesiątych.
mouviciel

@RossPatterson, ten komentarz naprawdę musi być odpowiedzią.
John R. Strohm

Odpowiedzi:


14

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.

http://i.stack.imgur.com/wcAWD.png

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


7
Oryginalny papier na SCCS wspomina żadnych innych systemów, i wydaje się wskazywać, że to musiało pochodzić z samej terminologii. Z samego źródła wygląda to tak, jakby przed 1972/73 nie istniał system kontroli wersji.
Martijn Pieters

1
Nazwanie systemu kontroli kodu źródłowego „Systemem kontroli kodu źródłowego” rzeczywiście wskazuje, że było to pierwsze wystąpienie czegoś, co później stałoby się kategorią oprogramowania.
Ingo

@MartijnPieters Rochkind uznaje CLEAR Browna na końcu artykułu i po prostu budując SCCS na OS / MVT, nie mógł nie wiedzieć o IEBUPDTE.
Ross Patterson

@RossPatterson: ani CLEAR, ani IEBUPDTE nie są systemami kontroli źródła. CLEAR przypisuje się ideę delt, wyraźnie stwierdza w dokumencie, że nie ma innych podobieństw.
Martijn Pieters

3

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.


Komendy CDC MODIFY i UPDATE były narzędziami do stosowania aktualizacji oprogramowania, a nie do zarządzania zmianami we własnym oprogramowaniu, o ile wiem. Zobacz apps.dtic.mil/dtic/tr/fulltext/u2/a208003.pdf , w którym opisano narzędzia na stronie o numerze 52 (61 w pliku PDF) oraz computinghistory.org.uk/downloads/39256 , który opisuje materiały do ​​wydania oprogramowania na nr 4 (PDF nr 16) w formacie UPDATE.
Martijn Pieters

Uważam, że Xerox SPUDS (Source Program Update Disk System) był podobnym pakietem.
Martijn Pieters

2

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ą.


Czy IEBUDTE nie jest systemem aktualizacji oprogramowania? Jest podobny do patcha, więc najlepiej komponent systemu kontroli wersji. O ile wiem, nie ma wykresu zmian w czasie.
Martijn Pieters

Tak, IEBUPDTEjest podobny do patch.
Ross Patterson
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.