Jak działała kontrola wersji na mikrokomputerach w latach 80. i 90.?

Jestem ciekawy, jak zespoły programistów zazwyczaj zarządzały tworzeniem oprogramowania w latach 80. i na początku 90. Czy cały kod źródłowy był po prostu przechowywany na jednym komputerze, nad którym wszyscy pracowali, czy też źródło było przekazywane i kopiowane ręcznie za pomocą dyskietki i scalane ręcznie, czy też faktycznie korzystali z systemów kontroli wersji przez sieć (na przykład CVS), tak jak to robimy teraz? A może użyto czegoś takiego jak offline CVS?

W dzisiejszych czasach każdy jest zależny od kontroli źródła. To oczywiste. Ale w latach 80. konfiguracja sieci komputerowych nie była tak łatwa, a takie rzeczy jak najlepsze praktyki wciąż były wymyślane ...

Wiem, że w latach 70. i 60. programowanie było zupełnie inne, więc kontrola wersji nie była konieczna. Ale w latach 80. i 90. ludzie zaczęli używać komputerów do pisania kodu, a aplikacje zaczęły zwiększać swój rozmiar i zakres, więc zastanawiam się, jak ludzie to wtedy zarządzali.

Czym się to różni między platformami? Powiedz Apple vs Commodore 64 vs Amiga vs MS-DOS vs Windows vs Atari

Uwaga: Mówię głównie o programowaniu na dzisiejszych mikrokomputerach , a nie na dużych komputerach z systemem UNIX.

Po pierwsze, kiedy pojawiły się mikrokomputery, oprogramowanie pisano głównie w systemach Unix lub VMS i „kompilowano / składano” w systemie docelowym. Te systemy komputerowe były wieloużytkownikowe, często z wieloma terminalami, i miały systemy kontroli kodowane źródłowo, takie jak SCCS .

Sieciowanie było opcją na mikrokomputerach od połowy lat 80., często podłączonych do systemu uniksowego jako „serwer plików” (może tylko za pomocą RS232 i Kermit do przesyłania plików, z SCCS w systemie Unix)

Zobacz Historię kontroli wersji autorstwa Erica Sink, aby uzyskać przegląd zmian w systemie kontroli wersji na przestrzeni lat.

Pamiętam, jak czytałem o kontroli kodu źródłowego w „BYTE” pod koniec lat 80. XX wieku, więc do tego czasu musiał on być używany w „małych systemach”.

SourceSafe został dobrze ustalony w połowie lat 90. na Dos, Windows itp.

Ten link pokazuje artykuł o PVCS działającym na PC od 1994 roku , jest w wersji 6.2, więc najwyraźniej już od pewnego czasu, Wikipedia twierdzi, że pochodzi z 1985 roku .

Jednak numerowane dyskietki były używane przez większość programistów pracujących na małym oprogramowaniu do późnych lat 90. XX wieku, do zastąpienia ich folderami na dysku twardym, tworząc kopię kodu źródłowego każdego dnia.

Pamiętam, jak pracowałem nad projektem przenoszącym oprogramowanie z Unit na Windows NT 3.5. Programiści, którzy wiedzą, jak programować w systemie Windows, często nawet nie słyszeli o kontroli kodu źródłowego w tym czasie.

Oś czasu pochodzi z postu na blogu autorstwa codicesoftware , sprzedają one Plastic SCM, jednak przegląd historii innych systemów wydaje się rozsądny, kilka starszych systemów przed pozostawieniem RCS z obrazu.

Prawdopodobnie nie jest to reprezentatywne dla całej branży gier, ale działało dobrze w naszej małej firmie gier. Nigdy nie współpracowałem z oprogramowaniem biznesowym, które prawdopodobnie miało inne wymagania.

Od połowy lat 80. do połowy lat 90. często używałem numeru wersji na końcu nazwy pliku, np. „Game.003”. Wtedy programowałem 90% w asemblerze, a cały kod był w jednym ogromnym pliku, prawdopodobnie z jednym lub dwoma dołączeniami, gdzie musiałbym ręcznie aktualizować numer wersji, gdy wszystko się zmieniało. Zwiększałem liczbę dopiero po tym, jak miałem stabilną wersję, którą z pewnością chciałem zachować.

To ostatecznie skalowało się dość wygodnie do około 3 osób. Potem powiększyliśmy zespół i skończyło się to bałaganem plików przez cały rok, dopóki nie miałem dość próbowania wyśledzenia zmian poszczególnych ludzi i zaczęliśmy używać Perforce około 1997-98.

Musisz to zobaczyć w kontekście ówczesnej wspólnej infrastruktury. Na początku lat 80. IBM wydał „komputer osobisty” i można to potraktować dosłownie. Najczęstszym sposobem tworzenia aplikacji na PC był jeden facet, który coś tworzył i próbował to sprzedać. Jedna dyskietka na wydaną wersję prawdopodobnie byłaby powszechna. Możesz kupić ładne kolorowe etykiety i napisać na nim nazwę swojego produktu oraz wersję. Przez większość udanych produktów tamtych czasów znałeś nazwisko faceta, który to napisał.

Sieci zostały wprowadzone jako dodatki. Interfejsy API klienta zostały zhakowane do DOS, a części serwera były dedykowane, opatentowane systemy operacyjne na osobnej maszynie. Zwykle drogi (nie dla mas) i po prostu oferuje udostępnianie plików i drukarek. W świecie komputerów sytuacja zaczęła się zmieniać wraz z wprowadzeniem systemu Windows for Workgroups i Windows NT. To otworzyło wiele możliwości. Sieć została w końcu zintegrowana ze środowiskiem znanym programistom, a programista Windows mógł pisać aplikacje, które mogły rozmawiać ze sobą przez sieć. To był koniec NetWare jako dominującego sieciowego systemu operacyjnego.

Wkrótce pojawiło się kilka systemów kontroli wersji z komponentami klienta i serwera, które można łatwo zainstalować na dowolnej kombinacji komputerów. Z wtyczkami dla IDE i komponentów klienta obsługującymi opcje wiersza poleceń, które umożliwiły integrację z systemem kompilacji.

Po tym, jak Internet wystartował i dostęp do Internetu stał się wszechobecny, dostałeś ruch open source i systemy kontroli źródła oparte na sieci. Zabawne jest to, że po wprowadzeniu komputera PC było to odważne przejście od scentralizowanego przetwarzania do przetwarzania rozproszonego. Ale definicja centralna kontra rozproszona jest niewyraźna. Czy chmura jest ostateczną dystrybucją, czy tylko nowy potworny komputer centralny, który ma całą moc, podobnie jak kiedyś komputer mainframe IBM?

W latach 90. zdecydowanie używałem oprogramowania do kontroli wersji. Był SCCS, a MPW firmy Apple miał wbudowaną kontrolę wersji (Projektor). I myślę, że korzystałem z Projektora około 1992 roku. W jednej firmie system kontroli wersji był dużą szafką z dyskietkami każdej wersji, wykonywaną raz w tygodniu.

Pierwszą wakacyjną pracą programistyczną, gdy jeszcze byłem w szkole (wydaje mi się, że byłoby to około 91), było wdrożenie automatycznego systemu zarządzania wersjami i tworzenia kopii zapasowych dla małej firmy, w której pracowałem. Mieliśmy 3 elementy podłączone do serwera netware, a właściciel w końcu zmęczył się rozwiązywaniem konfliktów wersji i opracowywaniem potrzebnych kopii zapasowych na dyskietkach, więc sprawiliśmy, że programiści pracowali na własnym komputerze, a nie bezpośrednio w plikach przechowywanych na serwerze tak jak do tej pory, a ja napisałem system, który zapisywał wszystkie swoje pliki tylko do odczytu, dopóki nie uruchomił programu sprawdzającego, że nikt ich nie używa, a następnie zarejestrował użycie w centralnej bazie danych btrieve (relacyjna baza danych z prostym zapytaniem API zamiast pełnego SQL, który działał na serwerze Netware). Inny program sprawdził ich zmodyfikowane zmiany i skopiował je na serwer,

Chociaż ten system został zbudowany na zamówienie dla małej firmy, w której pracowałem, wyobrażam sobie, że wiele podobnych sklepów miało podobne procesy.

Z własnego doświadczenia: 1985 PC-rozwój MS-DOS PVCS był dostępny i zbyt drogi. W przypadku komputerów Apple i wszystkich komputerów innych niż MSDOS: nic. Użyłem T-lib (50 USD) od 1987 roku. Porty Unix (SCCS), zacząłem filtrować około 1990 roku, SourceSafe około 1992 roku.

Do 1995 roku, jeśli nie korzystałeś z VCS, nie mówiłeś poważnie.

W latach 1993-1995 pracowałem z menedżerem emerytalnym z 15 programistami zajmującymi się programowaniem C / C ++ w SunOS z SPARCStation 20s i Sun IPX. Nasza baza kodów znajdowała się w katalogach montowanych przez NFS. Początkowo zajmowaliśmy się kopiowaniem wersji folderów , ale w pewnym momencie przenieśliśmy się do SCCS i niektóre zespoły zaczęły używać RCS .

W 1995 roku przeniosłem się do innej firmy z ponad 80 programistami pracującymi nad C / C ++ w Nowym Jorku, Londynie i Hongkongu. Użyliśmy ClearCase z dodatkiem do wielu witryn do zarządzania środowiskiem programistycznym.

ClearCase był dobry w synchronizowaniu bazy kodu między witrynami, ale w tym czasie wymagał prawie pełnego etatu administratora, aby utrzymać działanie. Było to również znacznie wolniejsze, ponieważ ClearCase prezentuje pliki w wirtualnym systemie plików, z konfiguracją określającą wersje katalogów i nazw plików ze znakami wieloznacznymi na podstawie gałęzi, czasu i / lub znaczników. W przypadku patologicznym można określić, że każdy pojedynczy plik ma inną wersję.