Come funzionava il controllo della versione sui microcomputer del giorno negli anni '80 e '90?

In primo luogo, quando i microcomputer escono per la prima volta, il software è stato principalmente scritto su sistemi Unix o VMS e "cross-compilatore / assemblato" sul sistema di destinazione. Questi sistemi informatici erano multiutente spesso con molti terminali e avevano sistemi di controllo con codice sorgente come SCCS .

La rete era un'opzione sui microcomputer a partire dalla metà degli anni '80, spesso collegata a un sistema Unix come "file server" (forse usando solo RS232 e Kermit per trasferire i file, con SCCS sul sistema Unix)

Vedi Una cronologia del controllo della versione di Eric Sink per avere una panoramica su come è cambiato il sistema di controllo della versione gli anni.

Ricordo di aver letto sul controllo del codice sorgente in "BYTE" alla fine degli anni '80, quindi deve essere stato in uso su "piccoli sistemi" per allora.

SourceSafe è stato ben consolidato a metà degli anni '90 su Dos, Windows, ecc.

Questo link mostra un articolo su PVCS in esecuzione su PC dal 1994 , è in versione 6.2 era evidentemente da un po 'di tempo, Wikipedia dice che risale al 1985 .

Tuttavia, i floppy disk numerati sono stati usati dalla maggior parte dei programmatori che lavorano su software su piccola scala fino alla fine degli anni '90, per essere sostituiti con cartelle sul loro disco rigido, facendo ogni giorno una copia del codice sorgente.

Ricordo di aver lavorato su un progetto di porting di software da Unit a Windows NT 3.5. I programmatori che sanno programmare per Windows spesso non avevano nemmeno sentito parlare del controllo del codice sorgente in quel momento.

Questa cronologia è tratta da un post sul blog di codicesoftware , vendono Plastic SCM tuttavia, la panoramica della storia di altri sistemi sembra ragionevole, alcuni sistemi meno recenti prima che RCS rimanga dell'immagine.

Probabilmente questo non è rappresentativo per l'industria dei giochi in generale, ma ha funzionato bene nella nostra piccola società di giochi. Mai lavorato con il software aziendale, che probabilmente aveva altri requisiti.

Dalla metà degli anni '80 fino alla metà degli anni '90 ho usato spesso un numero di versione alla fine del nome del file, ad es. "Game.003". Allora stavo programmando il 90% in assembler e tutto il codice era in un unico enorme file, possibilmente con uno o due include, dove dovevo manualmente aggiornare il numero di versione come le cose cambiate. Aumenterei solo il numero dopo aver avuto una versione stabile che ero sicuro di voler mantenere.

Questo alla fine si ridimensionò in qualche modo a circa 3 persone. Dopodiché siamo cresciuti e abbiamo avuto un sacco di file dappertutto per circa un anno, fino a quando non mi sono stancato di cercare di rintracciare i cambiamenti delle persone e abbiamo iniziato a utilizzare Perforce intorno al 1997-98.

Devi vedere questo nel contesto delle infrastrutture comuni in quel momento. Nei primi anni '80 IBM ha rilasciato il "personal computer" e puoi prenderlo alla lettera. Il modo più comune per sviluppare applicazioni per PC era un ragazzo che creava qualcosa e cercava di venderlo. Quindi un floppy per versione rilasciata sarebbe probabilmente comune. Potresti comprare delle belle etichette colorate e scrivere il nome del tuo prodotto e la versione su di esso. Per la maggior parte dei prodotti di successo di quei giorni conoscevi il nome del ragazzo che lo ha scritto.

Le reti sono state introdotte come componenti aggiuntivi. Le API del client sono state hackerate in DOS e le parti del server sono state dedicate, sistemi operativi propiziatori su una macchina separata. Generalmente costoso (non per le masse) e fondamentalmente solo offrendo condivisione di file e stampanti. Nel mondo dei PC le cose hanno iniziato a cambiare con l'introduzione di Windows per Workgroup e Windows NT. Questo ha aperto molte possibilità. Il networking è stato finalmente integrato nell'ambiente di cui un programmatore era abituato e un programmatore di Windows poteva scrivere applicazioni che potessero comunicare tra loro attraverso la rete. Questa era la fine di NetWare come sistema operativo di rete dominante.

Presto diversi sistemi di controllo delle versioni sono comparsi con componenti client e server che è possibile installare facilmente su qualsiasi combinazione di macchine. Con i plug-in per i componenti IDE e client che supportano le opzioni della riga di comando che hanno consentito l'integrazione in un sistema di compilazione.

Dopo che il web è decollato e l'accesso al PC su Internet è diventato onnipresente, hai ottenuto il movimento open source e i sistemi di controllo del codice sorgente basati sul web. La cosa divertente è che, quando è stato introdotto il PC, questo è stato visto come una mossa coraggiosa dall'informatica centralizzata all'elaborazione distribuita. Ma la definizione di centrale rispetto a quella distribuita è confusa. Il cloud è la distribuzione definitiva o è solo il nuovo mostro centrale che contiene tutta la potenza, proprio come era il mainframe IBM?

Negli anni '90 ho definitivamente usato il software per il controllo della versione. C'era SCCS e l'MPW di Apple aveva il controllo di versione integrato (Proiettore). E penso di aver usato Projector intorno al 1992. In una società il sistema di controllo della versione era un grande armadio con dischetti di ogni versione, preso una volta alla settimana.

Il mio primo lavoro di programmazione estiva mentre ero ancora tornato a scuola (questo sarebbe stato circa 91 credo) è stato quello di implementare un sistema di gestione e backup delle versioni automatizzato per la piccola azienda a cui stavo lavorando. Avevamo 3 PC collegati a un server NetWare, e il proprietario si era finalmente stancato di gestire i conflitti di versione e capire cosa fosse necessario fare il backup dei floppy, così abbiamo fatto lavorare gli sviluppatori sul loro PC piuttosto che direttamente nei file memorizzati sul server come avevano fatto fino ad ora, e ho scritto un sistema che teneva tutti i loro file impostati in sola lettura fino a quando non eseguivano un programma che non verificava che nessun altro li stesse usando, quindi registrava l'uso su un database centrale di btrieve (un database relazionale con una semplice query api piuttosto che full sql che girava sul server NetWare). Un altro programma ha controllato le loro modifiche modificate e le ha copiate sul server, e un terzo è stato eseguito alla fine di ogni giorno per copiare tutto ciò che è stato cambiato su un dischetto.

Mentre questo sistema era costruito su misura per la piccola azienda in cui lavoravo, immagino che molti negozi simili avessero processi simili.

Dall'esperienza personale: il PVC in sviluppo di MS-DOS del 1985 era disponibile e troppo costoso. Per Apple e tutti i PC non MSDOS: niente. Ho usato T-lib ($ 50) dal 1987. Porte Unix (SCCS), ho iniziato a filtrare verso il basso intorno al 1990, SourceSafe verso il 1992.

Nel 1995, se non stavi usando un VCS non eri serio.

Nel 1993-1995 ero in pensione con 15 sviluppatori che sviluppavano C / C ++ in SunOS con SPARCStation 20s e Sun IPX. Il nostro codebase era nelle directory montate NFS. Inizialmente stavamo facendo Controllo delle versioni delle cartelle di copia , ma a un certo punto ci siamo spostati su SCCS e alcuni team hanno iniziato a utilizzare RCS .

Nel 1995 mi sono trasferito in un'altra azienda con oltre 80 sviluppatori che sviluppavano C / C ++ a New York, Londra e Hong Kong. Abbiamo utilizzato ClearCase con l'add-on multi-sito per gestire l'ambiente di sviluppo.

ClearCase era bravo a sincronizzare la base di codice tra siti, ma al momento richiedeva quasi un amministratore a tempo pieno per far funzionare le cose. È stato anche molto più lento perché ClearCase presenta i file in un filesystem virtuale, con una configurazione che specifica le versioni di directory e nomi di file con caratteri jolly basati su rami, tempo e / o tag. In un caso patologico, è possibile specificare ogni singolo file per avere una versione diversa.