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

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

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

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

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

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

Во-первых, когда впервые появились микрокомпьютеры, программное обеспечение было написано в основном на системах 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 остались от образа.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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