Comment le contrôle de version fonctionnait-il sur les micro-ordinateurs de l'époque dans les années 80 et 90?

Je suis curieux de savoir comment les équipes de programmeurs géraient généralement leur développement logiciel dans les années 80 et au début des années 90. Tout le code source était-il simplement stocké sur une machine sur laquelle tout le monde travaillait, ou la source était-elle transmise et copiée manuellement via une disquette et fusionnée manuellement, ou utilisaient-ils réellement des systèmes de contrôle des révisions sur un réseau (CVS par exemple) comme nous le faisons à présent? Ou peut-être que quelque chose comme un CVS hors ligne était utilisé?

De nos jours, tout le monde dépend du contrôle des sources .. c'est une évidence. Mais dans les années 80, les réseaux informatiques n'étaient pas si faciles à mettre en place, et des choses comme les meilleures pratiques étaient toujours en cours d'élaboration ...

Je sais que dans les années 70 et 60, la programmation était assez différente, donc le contrôle des révisions n'était pas nécessaire. Mais c'est dans les années 80 et 90 que les gens ont commencé à utiliser des ordinateurs pour écrire du code, et les applications ont commencé à augmenter en taille et en portée, alors je me demande comment les gens ont géré tout cela à l'époque.

En outre, en quoi cela diffère-t-il entre les plates-formes? Dites Apple contre Commodore 64 vs Amiga vs MS-DOS vs Windows vs Atari

Remarque: je parle principalement de la programmation sur les micro - ordinateurs de l'époque, pas sur les grosses machines UNIX.

Premièrement, lorsque les micro-ordinateurs sont sortis pour la première fois, le logiciel a été principalement écrit sur des systèmes Unix ou VMS et «compilateur croisé / assemblé» sur le système cible. Ces systèmes informatiques étaient souvent multi-utilisateurs avec de nombreux terminaux et disposaient de systèmes de contrôle à code source comme SCCS .

La mise en réseau était une option sur les micro-ordinateurs à partir du milieu des années 1980, souvent connectée à un système Unix comme "serveur de fichiers" (peut-être simplement en utilisant RS232 et Kermit pour transférer les fichiers, avec SCCS sur le système Unix)

Voir Une histoire du contrôle de version par Eric Sink pour avoir un aperçu de la façon dont le système de contrôle de version a changé au fil des ans.

Je me souviens d'avoir lu sur le contrôle du code source dans "BYTE" à la fin des années 1980, il devait donc être utilisé sur les "petits systèmes" à ce moment-là.

SourceSafe était bien établi au milieu des années 90 fonctionnant sur Dos, Windows, etc.

Ce lien montre un article sur PVCS fonctionnant sur PC à partir de 1994 , il est à la version 6.2, donc il était clair qu'il existait depuis un certain temps, Wikipedia dit qu'il date de 1985 .

Cependant, la plupart des programmeurs travaillant sur des logiciels à petite échelle ont utilisé des disquettes numérotées jusqu'à la fin des années 1990, pour les remplacer par des dossiers sur leur disque dur, ce qui en fait une copie quotidienne du code source.

Je me souviens avoir travaillé sur un logiciel de portage de projet de Unit vers Windows NT 3.5. Les programmeurs qui savent programmer pour Windows n'avaient souvent même pas entendu parler du contrôle du code source à l'époque.

Cette chronologie est tirée d'un article de blog de codicesoftware , ils vendent Plastic SCM, mais la vue d'ensemble de l'histoire des autres systèmes semble raisonnable, quelques systèmes plus anciens avant que RCS ne restent de l'image.

Ce n'est probablement pas représentatif de l'industrie des jeux en général, mais cela a bien fonctionné dans notre petite société de jeux. Jamais travaillé avec des logiciels d'entreprise, qui avaient probablement d'autres exigences.

Du milieu des années 80 jusqu'au milieu des années 90, j'ai souvent utilisé un numéro de version à la fin du nom de fichier, par exemple "game.003". À l'époque, je programmais 90% dans l'assembleur et tout le code était dans un seul fichier énorme, éventuellement avec un ou deux inclus, où je devrais manuellement mettre à jour le numéro de version à mesure que les choses changeaient. Je n'augmenterais le nombre qu'après avoir eu une version stable que j'étais sûr de vouloir garder.

Cela a finalement évolué assez confortablement à environ 3 personnes. Après cela, nous avons agrandi l'équipe et nous avons fini par avoir un fouillis de fichiers un peu partout pendant un an environ jusqu'à ce que j'en ai marre d'essayer de suivre les changements individuels et que nous avons commencé à utiliser Perforce vers 1997-1998.

Il faut voir cela dans le contexte des infrastructures communes à l'époque. Au début des années 80, IBM a sorti "l'ordinateur personnel" et vous pouvez le prendre au pied de la lettre. La façon la plus courante de développer des applications pour un PC était qu'un gars crée quelque chose et essaie de le vendre. Donc, une disquette par version publiée serait probablement courante. Vous pouvez acheter de jolies étiquettes colorées et y écrire le nom de votre produit et sa version. Pour la plupart des produits à succès de cette époque, vous connaissiez le nom du gars qui l'a écrit.

Les réseaux ont été introduits en tant que modules complémentaires. Les API clientes ont été piratées sous DOS et les parties serveur étaient des systèmes d'exploitation dédiés et propriétaires sur une machine distincte. Généralement cher (pas pour les masses) et offrant simplement le partage de fichiers et d'imprimantes. Dans le monde du PC, les choses ont commencé à changer avec l'introduction de Windows pour Workgroups et Windows NT. Cela a ouvert de nombreuses possibilités. La mise en réseau a finalement été intégrée dans l'environnement qu'un programmeur connaissait bien et un programmeur Windows pouvait écrire des applications qui pouvaient communiquer entre elles sur le réseau. Ce fut la fin de NetWare en tant que système d'exploitation de réseau dominant.

Bientôt, plusieurs systèmes de contrôle de version sont apparus avec des composants client et serveur que vous pouvez facilement installer sur n'importe quelle combinaison de machines. Avec des plug-ins pour les composants IDE et clients prenant en charge les options de ligne de commande qui ont permis l'intégration dans un système de génération.

Après que le Web ait décollé et que l'accès des PC à Internet soit devenu omniprésent, vous avez obtenu le mouvement open source et les systèmes de contrôle des sources Web. Ce qui est drôle, c'est que lorsque le PC a été introduit, cela a été considéré comme un passage audacieux de l'informatique centralisée à l'informatique distribuée. Mais la définition de central contre distribué est floue. Le cloud est-il la distribution ultime ou est-ce simplement le nouvel ordinateur central monstre qui détient toute la puissance, un peu comme le mainframe IBM?

Dans les années 90, j'ai définitivement utilisé un logiciel pour le contrôle de version. Il y avait SCCS, et le MPW d'Apple avait un contrôle de version intégré (projecteur). Et je pense que j'ai utilisé Projector vers 1992. Dans une entreprise, le système de contrôle de version était un grand placard avec des disquettes de chaque version, pris une fois par semaine.

Mon premier travail de programmation d'été alors que j'étais encore à l'école (cela aurait été vers 91 je pense) a été d'implémenter un système de gestion de versions et de sauvegarde automatisé pour la petite entreprise dans laquelle je travaillais. Nous avions 3 ordinateurs connectés à un serveur netware, et le propriétaire était finalement fatigué de gérer les conflits de version et de trouver ce qui devait être sauvegardé sur les disquettes, nous avons donc fait travailler les développeurs sur leur propre ordinateur plutôt que directement dans des fichiers stockés sur le serveur. comme ils l'avaient fait jusqu'à présent, et j'ai écrit un système qui gardait tous leurs fichiers en lecture seule jusqu'à ce qu'ils exécutent un programme qui vérifiait que personne d'autre ne les utilisait, puis enregistrait l'utilisation sur une base de données btrieve centrale (une base de données relationnelle avec une simple requête api plutôt que sql complet exécuté sur le serveur netware). Un autre programme a vérifié leurs modifications modifiées et les a copiées sur le serveur,

Bien que ce système ait été conçu sur mesure pour la petite entreprise dans laquelle je travaillais, j'imagine que de nombreux magasins similaires avaient des processus similaires.

D'après mon expérience personnelle: 1985 Le développement en réseau MS-DOS PVCS était disponible et trop cher. Pour Apple et tous les PC non MSDOS: rien. J'ai utilisé T-lib (50 $) à partir de 1987. Les ports Unix (SCCS), ont commencé à filtrer vers 1990, SourceSafe vers 1992.

En 1995, si vous n'utilisiez pas de VCS, vous n'étiez pas sérieux.

En 1993-1995, j'étais avec un gestionnaire de pension avec 15 développeurs faisant du développement C / C ++ dans SunOS avec SPARCStation 20 et Sun IPX. Notre base de code se trouvait dans des répertoires montés NFS. Au début, nous faisions la copie des versions de dossiers , mais à un moment donné, nous sommes passés à SCCS et certaines équipes ont commencé à utiliser RCS .

En 1995, j'ai déménagé dans une autre entreprise avec plus de 80 développeurs faisant du développement C / C ++ à New York, Londres et Hong Kong. Nous avons utilisé ClearCase avec le module complémentaire multisite pour gérer l'environnement de développement.

ClearCase était capable de synchroniser la base de code entre les sites, mais à l'époque, il fallait presque un administrateur à temps plein pour que les choses fonctionnent. Il était également beaucoup plus lent car ClearCase présente les fichiers dans un système de fichiers virtuel, avec une configuration spécifiant les versions des répertoires et les noms de fichiers génériques basés sur les branches, l'heure et / ou les balises. Dans un cas pathologique, on pourrait spécifier que chaque fichier individuel a une version différente.