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

31

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.

9a3eedi
źródło
3
RCS został pierwotnie wydany w 1982 r.
grudnia 2012 r.
1
Ale ile osób z niego korzystało? RCS został stworzony przez AFAIK dla systemów uniksowych i podobnych do unixowych, które nie działały na mikrokomputerach.
9a3eedi
2
Mieliśmy systemy sieciowe. Po prostu nie zostało rozliczone na tcp / ip, były też inne, takie jak decnet. Udostępnianie plików było dostępne w kilku protokołach. Zespoły opracowywały minis nawet dla micros, chociaż niektórzy mali niezależni programiści (nie w zespołach), po prostu tworzyli kopie zapasowe zamiast wersji przy użyciu formalnej kontroli. Niektórzy mogą emulować kontrolę wersji za pomocą rygorystycznych ręcznych kopii zapasowych.
Erik Eidt
2
Zrobiliśmy to bardzo ostrożnie, głównie w oprogramowaniu mokrym, ponieważ to, co myślisz o kontroli wersji, nie istniało na wspomnianych platformach.
Blrfl
2
W moim przypadku na początku lat 80. używaliśmy talii kart dziurkaczy do minikomputerów. Czasami zapisywaliśmy talie kodów źródłowych w szafkach kart perforowanych.
Gilbert Le Blanc

Odpowiedzi:

22

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.


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.

Oś czasu historii kontroli wersji

Ian
źródło
1
kiedy zacząłem pracować, korzystałem z VSS .. podoba mi się powitanie w piekle . Pamiętam, że mój szef zespołu zapytał mnie, czy warto zmienić się na perforce ... do diabła tak!
draeron
@draeron, stwierdziłem, że VSS był OK, jeśli nie spodziewałeś się, że będziesz mógł scalić gałęzie ORAZ na stabilnym serwerze plików. Jedna firma, dla której pracowałem, miała to na serwerze ze złymi układami pamięci RAM, więc ciągle uszkadzała bazę danych! Dajcie mi jednak perfekcję zamiast każdego dnia tygodnia ...
Ian
„Witaj w piekle” może również dotyczyć Clearcase… wzdrygnąć się
Andrew Kennan
13

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.

axl
źródło
6

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?

Martin Maat
źródło
1
Netware nadal było dość dominujące, dopóki Active Directory nie uruchomiło się z win2k. Netware wciąż ma wiele rzeczy, w których AD nie może obejść się bez poważnych problemów.
Wyatt Barnett
Więc mówisz, że w tym czasie ludzie z mikrokomputerami nie używali kontroli źródła, ponieważ nie potrzebowali jej? tzn. zazwyczaj tylko jeden facet tworzył programy w swoim domu, więc nie musisz współdzielić kodu ani wykonywać fuzji?
9a3eedi
2
@ 9a3eedi: Maluję typowy obraz. Ludzie mogli odczuwać potrzebę, ale po prostu jej nie było, więc żyliście swoimi środkami. Scalasz mówisz? To brzmi jak duży skomplikowany program. Ile pamięci potrzebuje taka bestia? Co pozostanie do scalenia kodu? Mogę wymieniać dyskietki, ale jeśli moja pamięć jest pełna, gdzie mam iść ?! Było to możliwe, dopóki ludzie nie mieli „całej pamięci, jakiej kiedykolwiek potrzebowaliby” (jak 640 KB).
Martin Maat,
5

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.

gnasher729
źródło
SCCS nie działał na mikrokomputerach. I nie mógł działać, ponieważ polegał na funkcji wyłącznie specyficznej dla systemu plików Solaris (nawet ogólnego systemu Unix)
gnat
1
@gnat - czy mówisz o tym samym SCCS ? Wiem, że użyłem go na Next w połowie lat 90. i wierzę, że użyłem go na różnych uniksowych Solarisach pod koniec lat 80. Linkowany artykuł z Wikipedii wydaje się zgadzać, że nie był to tylko Solaris.
kdgregory
3
Jestem całkiem pewien, że użyłem SCCS na 3B2-400 z systemem Sys V około 1986 roku. ISTR, że użyliśmy go zamiast RCS, ponieważ współpracowaliśmy z konsultantem, którego firma użyła go w systemie Xenix opartym na Z8000 i miał pewne makefile, które to założyły zastosowano.
TMN
1
Zdecydowanie użyłem SCCS w 1984 r. Na Microsoft Xenix na procesorach Motorola 68000.
Charles E. Grant
2
Prawdą jest, że Linux nie obsługiwał SCCS w latach 80. Jeśli o to chodzi, w latach 80. XIX wieku brakowało również obsługi SCCS w Linuksie. SCCS i inne programy (np. Czytnik wiadomości rn) w latach 80-tych Unix używał open (2) do tworzenia doradczych plików blokujących, które działały, jeśli wszyscy użytkownicy przestrzegali tego samego protokołu. Ponieważ SCCS tworzył blokady doradcze, z pewnością można je uszanować.
msw
1

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.

Jules
źródło
1

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.

david.pfx
źródło
Zmieniłbym
@mark: Wątpię, aby było tak w przypadku rozwoju na PC. Korporacje najczęściej ignorowały komputery do Windows 3.
david.pfx
Było dużo programowania w DOS i do 86 roku korzystałem z PVCS, a nowi dołączający mieli doświadczenie w Uniksie, ale jak zauważyłem, było to w bankowości i finansach, więc moglibyśmy być wyprzedzeni
użytkownik151019
@mark: PVCS był zdecydowanie dostępny do 1985 r., ale był zbyt drogi dla większości użytkowników (000 USD). Korzystali z niego tylko ci, którzy przeprowadzają się z większych systemów i mają pieniądze na spalenie.
david.pfx
-1

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

Ed Griebel
źródło
1
Pytanie dotyczy konkretnie informacji o mikrosystemach innych niż Unix, ale systemy, które opisujesz, były (w tym czasie) dostępne tylko na stacjach roboczych unix.
Jules