Как работал контроль версий на микрокомпьютерах дня в 80-х и 90-х годах?

31

Мне любопытно узнать, как команды программистов обычно управляли разработкой программного обеспечения в 80-х и начале 90-х годов. Был ли весь исходный код просто храниться на одной машине, на которой все работали, или же источник передавался и копировался вручную с дискеты и сливался вручную, или они действительно использовали системы контроля версий по сети (например, CVS), как мы это делаем? в настоящее время? Или, может быть, использовалось что-то вроде автономного CVS?

В настоящее время все зависят от контроля над источниками ... это легко. Но в 80-х компьютерные сети было не так легко настроить, и такие вещи, как лучшие практики, все еще находились в процессе ...

Я знаю, что в 70-х и 60-х программирование было совсем другим, поэтому контроль версий не был необходим. Но в 80-х и 90-х годах люди начали использовать компьютеры для написания кода, и приложения стали увеличиваться в размерах и масштабах, поэтому мне интересно, как люди тогда справлялись со всем этим.

Кроме того, как это отличается между платформами? Скажем, Apple против Commodore 64 против Amiga против MS-DOS против Windows против Atari

Примечание: я в основном говорю о программировании на современных микрокомпьютерах , а не на больших машинах UNIX.

9a3eedi
источник
3
RCS был первоначально выпущен в 1982 году.
5gon12eder
1
Но сколько людей использовали это? RCS был AFAIK для Unix и Unix-подобных машин, которые не работали на микрокомпьютерах.
9a3eedi
2
У нас были сетевые системы. Просто не остановился на tcp / ip, были и другие, вроде decnet. Совместное использование файлов было доступно в нескольких протоколах. И команды занимались разработкой на мини даже для микро, хотя некоторые маленькие независимые разработчики (не в командах) просто делали резервные копии вместо версии, используя формальный контроль. Некоторые могут эмулировать управление версиями с помощью строгих ручных резервных копий.
Эрик Эйдт
2
Мы делали это очень осторожно, в основном в мокром программном обеспечении, потому что то, что вы считаете контролем версий, не существовало на упомянутых вами платформах.
Blrfl
2
В моем случае мы использовали колоды перфокарт для мини-компьютеров в начале 1980-х годов. Иногда мы сохраняли колоды исходного кода в картотечных шкафах с перфокартами.
Гилберт Ле Блан

Ответы:

22

Во-первых, когда впервые появились микрокомпьютеры, программное обеспечение было написано в основном на системах Unix или VMS и «кросс-компилировалось / собиралось» в целевой системе. Эти компьютерные системы были многопользовательскими, часто со многими терминалами, и имели системы управления с исходным кодом, такие как SCCS .

Сетевые соединения были опцией для микрокомпьютеров с середины 1980-х годов, которые часто подключались к системе Unix в качестве «файлового сервера» (возможно, просто используя RS232 и Kermit для передачи файлов, с SCCS в системе Unix)

Посмотрите «Историю контроля версий » Эрика Синка, чтобы получить представление о том, как система контроля версий изменилась за эти годы.

Я помню, как читал об управлении исходным кодом в «BYTE» в конце 1980-х годов, так что к тому времени он уже использовался в «малых системах».

SourceSafe хорошо зарекомендовал себя к середине 90-х годов, работая на Dos, Windows и т. Д.

Эта ссылка показывает статью о PVCS, работающей на ПК с 1994 года , она имеет версию 6.2, так что она явно была в течение некоторого времени, в Википедии говорится, что она датируется 1985 годом .


Однако пронумерованные гибкие диски использовались большинством программистов, работающих над маломасштабным программным обеспечением до конца 1990-х годов, и заменялись папками на жестком диске, делая ежедневную копию исходного кода.

Я помню, как работал над программным обеспечением для переноса проекта с устройства на Windows NT 3.5. Программисты, которые знают, как программировать для Windows, часто даже не слышали об управлении исходным кодом в то время.


Эта временная шкала взята из сообщения в блоге codicesoftware , они продают Plastic SCM, однако обзор истории других систем кажется разумным - несколько более старых систем до того, как RCS остались от образа.

Хронология истории контроля версий

Ян
источник
1
когда я начал работать, я использовал VSS .. мне нравится комментарий " Добро пожаловать в ад" . Я помню, как меня попросил руководитель команды, стоит ли менять на выступления ... черт возьми, да!
draeron
@draeron, я обнаружил, что VSS был в порядке, если вы не ожидали, что сможете объединить ветви, и он был на стабильном файловом сервере. Одна компания, в которой я работал, имела сервер с плохими чипами памяти, поэтому продолжала портить базу данных! Однако вместо этого дайте мне выступление в любой день недели ...
Ян
«Добро пожаловать в ад» может также относиться к Clearcase ... дрожь
Эндрю Кеннан
13

Вероятно, это не характерно для игровой индустрии в целом, но это хорошо сработало в нашей небольшой игровой компании. Никогда не работал с программным обеспечением для бизнеса, у которого, вероятно, были другие требования.

С середины 80-х до середины 90-х годов я часто использовал номер версии в конце имени файла, например, «game.003». В то время я программировал на 90% на ассемблере, и весь код был в одном огромном файле, возможно, с одним или двумя включениями, где мне приходилось обновлять номер версии по мере изменения ситуации. Я увеличил бы число только после того, как у меня была стабильная версия, которую я был уверен, что хочу сохранить.

Это в конечном итоге несколько удобно для 3 человек. После этого мы увеличили команду и в течение года или около того разбирались с файлами по всему месту, пока мне не надоели попытки отследить изменения отдельных людей, и мы начали использовать Perforce примерно в 1997-98 годах.

Axl
источник
6

Вы должны увидеть это в контексте общих инфраструктур того времени. В начале 80-х IBM выпустила «персональный компьютер», и вы можете воспринимать это буквально. Самым распространенным способом разработки приложений для ПК был один человек, который что-то создавал и пытался продать. Таким образом, одна дискета на выпущенную версию, вероятно, будет распространена. Вы можете купить красивые цветные этикетки и написать название своего продукта и версию на нем. Для большинства успешных продуктов тех дней вы знали имя парня, который написал это.

Сети были представлены как дополнения. Клиентские API были взломаны в DOS, а серверные части были выделенными проприетарными операционными системами на отдельном компьютере. Как правило, дорого (не для широких масс) и просто предлагает общий доступ к файлам и принтерам. В мире ПК все изменилось с появлением Windows для рабочих групп и Windows NT. Это открыло много возможностей. Наконец, сеть была интегрирована в среду, с которой был знаком программист, и программист Windows мог писать приложения, которые могли общаться друг с другом по сети. Это был конец NetWare как доминирующей сетевой операционной системы.

Вскоре появилось несколько систем контроля версий с клиентскими и серверными компонентами, которые можно было легко установить на любую комбинацию компьютеров. С подключаемыми модулями для IDE и клиентских компонентов, поддерживающими параметры командной строки, которые обеспечивают интеграцию в систему сборки.

После того, как сеть взлетела, и доступ ПК к Интернету стал повсеместным, у вас появилось движение с открытым исходным кодом и системы управления исходным кодом через Интернет. Самое смешное, что когда появился ПК, это было смелым шагом от централизованных вычислений к распределенным вычислениям. Но определение центрального и распределенного размыто. Является ли облако окончательным распределением или это просто новый центральный компьютер-монстр, который обладает всей мощью, так же, как раньше был мэйнфрейм IBM?

Мартин Маат
источник
1
Netware все еще оставалась доминирующей, пока Active Directory не запустилась с win2k. В Netware по-прежнему есть много вещей, которые AD сделал хорошо, но без серьезных болтов.
Уайетт Барнетт
Так что вы говорите, что в то время люди с микрокомпьютерами не использовали контроль источников, потому что им это не нужно? то есть, как правило, только один парень делал программы в своем доме, поэтому не нужно делиться кодом или делать слияния?
9a3eedi
2
@ 9a3eedi: я рисую типичную картину. Люди, возможно, чувствовали потребность, но ее просто не было, поэтому вы жили своими средствами. Слияние говоришь? Это звучит как большая сложная программа. Сколько памяти нужно такому зверю? Что останется для кода, который будет объединен? Я могу поменять дискеты, но если моя память заполнена, куда мне идти ?! Это было до тех пор, пока у людей не было «всей памяти, которая им когда-либо понадобится» (например, 640K), что это стало возможным.
Мартин Маат
5

В 90-х я определенно использовал программное обеспечение для контроля версий. Был SCCS, и у Apple MPW был встроенный контроль версий (Projector). И я думаю, что использовал Projector около 1992 года. В одной компании система контроля версий представляла собой большой шкаф с дискетами каждой версии, которые брали раз в неделю.

gnasher729
источник
SCCS не работал на микрокомпьютерах. И не мог работать, потому что он опирался на особенность, специфичную исключительно для файловой системы Solaris (даже не универсальной Unix)
gnat
1
@gnat - ты говоришь об одном и том же SCCS ? Я знаю, что я использовал его на Next в середине 90-х, и считаю, что я использовал его на различных Unicals Solaris в конце 80-х. И связанная статья в Википедии, похоже, согласна с тем, что это не только Solaris.
kdgregory
3
Я уверен, что я использовал SCCS на 3B2-400 под управлением Sys V примерно в 1986 году. ISTR, что мы использовали его вместо RCS, потому что мы работали с консультантом, чья компания использовала его в их системе Xenix на базе Z8000, и у него были некоторые make-файлы, которые предполагали это использовался.
TMN
1
Я определенно использовал SCCS в 1984 году на Microsoft Xenix, работающей на процессорах Motorola 68000.
Чарльз И. Грант
2
Это правда, что Linux не поддерживал SCCS в 1980-х годах. По этой причине поддержка Linux для SCCS отсутствовала и в 1880-х годах. SCCS и другие программы (например, rn newsreader) под Unix 1980-х годов использовали open (2) для создания консультативных файлов блокировки, которые работали, если все пользователи подчинялись одному и тому же протоколу. Так как SCCS был единственным, кто создавал консультативные блокировки, можно было с уверенностью их уважать.
MSW
1

Моей первой летней работой по программированию, когда я еще учился в школе (думаю, это было около 91 года), было внедрение автоматизированной системы управления версиями и резервного копирования для небольшой фирмы, в которой я работал. У нас было 3 устройства, подключенных к сетевому серверу, и владелец, наконец, устал работать с конфликтами версий и решать, что нужно делать резервное копирование на дискеты, поэтому мы заставили разработчиков работать не на файлах, хранящихся на сервере, а на их собственных компьютерах. как и до сих пор, и я написал систему, в которой все их файлы оставались доступными только для чтения, пока они не запустили программу, которая проверяла, что никто другой не использует их, а затем записал использование в центральной базе данных btrieve (реляционной базе данных с простым запросом). API, а не полный SQL, который работал на сервере Netware). Другая программа проверила их измененные изменения и скопировала их на сервер,

Хотя эта система была специально разработана для небольшой фирмы, в которой я работал, я думаю, что во многих похожих магазинах были похожие процессы.

Жюль
источник
1

Из личного опыта: 1985 Сетевая разработка MS-DOS PVCS была доступна и слишком дорога. Для Apple и всех компьютеров без MSDOS: ничего. Я использовал T-lib ($ 50) с 1987 года. Порты Unix (SCCS) начали фильтроваться примерно в 1990 году, SourceSafe - в 1992 году.

К 1995 году, если вы не использовали VCS, вы не были серьезны.

david.pfx
источник
Я бы поменял последнее предложение на 1985 :( Но тогда я работал в сфере финансов
user151019
@ Марк: Я очень сомневаюсь, что это было верно для разработки на ПК. Корпорации в основном игнорировали ПК до Windows 3.
david.pfx
Было много программ для DOS, и к 86 году я использовал PVCS, а новые столяры имели опыт работы в Unix, но, как уже было отмечено, это было в банковском деле и финансах, поэтому мы могли быть впереди
user151019
@ mark: PVCS был определенно доступен к 1985 году, но для большинства пользователей он слишком дорогой (000 долларов). Его будут использовать только те, кто переходит из более крупных систем и имеет деньги на сжигание.
david.pfx
-1

В 1993-1995 годах я работал с менеджером по пенсиям с 15 разработчиками, которые занимались разработкой C / C ++ для SunOS с SPARCStation 20s и Sun IPX. Наша кодовая база была в смонтированных каталогах NFS. Изначально мы занимались версионированием папок , но в какой-то момент мы перешли на SCCS, и некоторые команды начали использовать RCS .

В 1995 году я перешел в другую компанию с 80+ разработчиками, занимающимися разработкой C / C ++ в Нью-Йорке, Лондоне и Гонконге. Мы использовали ClearCase с надстройкой для нескольких сайтов для управления средой разработки.

ClearCase хорошо справлялся с синхронизацией кодовой базы между сайтами, но в то время требовался почти полный администратор, чтобы все работало. Это также было намного медленнее, потому что ClearCase представляет файлы в виртуальной файловой системе с конфигурацией, определяющей версии каталогов и имен файлов с подстановочными символами, основанными на ветвях, времени и / или тегах. В патологическом случае можно указать для каждого отдельного файла свою версию.

Эд Грибель
источник
1
В этом вопросе содержится конкретная информация о не-unix-микросистемах, но описанные вами системы (в то время) были доступны только на рабочих станциях Unix.
Жюль