Як працював контроль версій на мікрокомп'ютерах у 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 тощо.

Це посилання показує статтю про ПВХ, що працює на ПК з 1994 року , вона знаходиться у версії 6.2, так явно існувала протягом певного часу, Вікіпедія говорить, що вона починається з 1985 року .

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

Пам’ятаю, працював над проектом перенесення програмного забезпечення від Unit до Windows NT 3.5. Програмісти, які вміють програмувати для Windows, часто навіть не чули про керування вихідним кодом.

Ця часова шкала взята з публікації блогу codicesoftware , вони продають Plastic SCM, однак огляд історії інших систем здається розумним, кілька старих систем, перш ніж RCS залишилися від зображення.

Це, мабуть, не є представником для ігрової індустрії взагалі, але це добре працювало в нашій невеликій ігровій компанії. Ніколи не працював з бізнес-програмним забезпеченням, яке, мабуть, мало інші вимоги.

З середини 80-х до середини 90-х я часто використовував номер версії в кінці назви файлу, наприклад, "game.003". Тоді я програмував 90% в асемблері, і весь код знаходився в одному величезному файлі, можливо, з одним або двома включеннями, де я вручну повинен був би оновити номер версії, коли все змінилося. Я збільшив би число лише після того, як у мене з'явилася стабільна версія, яку я був впевнений, що хочу зберегти.

Зрештою, це було зручно масштабувати приблизно до 3 людей. Після цього ми збільшили команду і в кінцевому підсумку протягом року або близько того, що я мав безлад файлів, поки я не втомився намагатися відстежувати зміни людей, і ми почали використовувати Perforce близько 1997-98.

Ви повинні бачити це в контексті загальної інфраструктури того часу. На початку 80-х IBM випустила "персональний комп'ютер", і ви можете сприйняти це досить буквально. Найпоширенішим способом розробки додатків для ПК був один хлопець, який щось створював, і намагався його продати. Отже, одна дискета за випущену версію, ймовірно, буде загальною. Ви можете придбати кілька приємних барвистих етикеток і написати на ньому продукт та версію на ньому. Більшість успішних продуктів тих днів ви знали ім'я хлопця, який його написав.

Мережі були введені як додатки. API клієнтів були взломані в DOS, а серверні частини були виділені, власні операційні системи на окремій машині. Як правило, дорого (не для маси) і в основному пропонують спільний доступ до файлів та принтерів. У світі ПК все почало змінюватись із впровадженням Windows for Workgroups та Windows NT. Це відкрило багато можливостей. Нарешті, мережа була інтегрована в середовище, з яким був знайомий програміст, і програміст Windows міг писати програми, які могли поговорити з іншими в мережі. Це було завершенням NetWare як домінуючої мережевої операційної системи.

Незабаром з'явилися декілька систем управління версіями з клієнтськими та серверними компонентами, які можна було легко встановити на будь-якій комбінації машин. Із плагінами для IDE та клієнтських компонентів, що підтримують параметри командного рядка, що дозволяють інтегруватись у систему збірки.

Після того, як Інтернет вийшов з мережі та доступ до ПК в Інтернеті став повсюдним, ви отримали рух з відкритим кодом та веб-системи управління джерелами. Найсмішніше, що коли ПК був представлений, це сприймалося як сміливий крок від централізованих обчислень до розподілених обчислень. Але визначення центрального проти розподіленого розмилося. Чи хмара є кінцевим розповсюдженням чи це просто новий центральний комп'ютер монстра, який тримає всю потужність, подібно до колишнього мейнфрейму IBM?

У 90-х я напевно використовував програмне забезпечення для контролю версій. Існував SCCS, і Apple MPW мав вбудований контроль версій (Проектор). Я думаю, що я використовував Projector близько 1992 року. На одній компанії система управління версіями являла собою великий шафа з дискетами кожної версії, що приймався раз на тиждень.

Моя перша літня робота з програмування, коли я ще був у школі (це було б приблизно 91 рік), - це впровадження автоматизованої системи управління версіями та резервного копіювання для невеликої фірми, в якій я працював. У нас було 3 комп’ютери, підключені до мережевого сервера, і власник, нарешті, втомився обробляти конфлікти версій та розробляти те, що потрібно для резервного копіювання дискети, тому ми змусили розробників працювати над власним ПК, а не безпосередньо у файлах, що зберігаються на сервері як у них досі, і я написав систему, яка зберігала всі їх файли, встановлені лише для читання, поки вони не запустили програму, яка перевіряла, що ніхто інший не використовує їх, а потім записав використання в центральну базу даних btrieve (реляційна база даних з простим запитом api, а не повний sql, який працював на сервері мереж). Інша програма перевірила їх змінені зміни та скопіювала їх на сервер,

Хоча ця система була побудована на замовлення для невеликої фірми, в якій я працював, я думаю, що багато подібних магазинів мали подібні процеси.

З особистого досвіду: 1985 р. Розроблена мережева розробка ПВХ MS-DOS була доступною і надто дорогою. Для Apple та всіх ПК, що не мають MSDOS: нічого. Я використав T-lib ($ 50) з 1987 року. Порти Unix (SCCS), почали фільтрувати близько 1990 року, SourceSafe - близько 1992 року.

До 1995 року, якщо ви не використовували СКС, ви не ставились до серйозних.

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

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

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