¿Cómo funcionaba el control de versiones en las microcomputadoras de la época en los años 80 y 90?

Tengo curiosidad por saber cómo los equipos de programadores generalmente manejaban su desarrollo de software en los años 80 y principios de los 90. ¿Todo el código fuente se almacenó simplemente en una máquina en la que todos trabajaron, o la fuente se pasó y copió manualmente a través de un disquete y se fusionó manualmente, o realmente usaron sistemas de control de revisión en una red (CVS, por ejemplo) como lo hacemos? ¿ahora? ¿O tal vez se estaba utilizando algo como un CVS sin conexión?

Hoy en día todos dependen del control de la fuente ... es obvio. Pero en los años 80, las redes de computadoras no eran tan fáciles de configurar, y todavía se estaban resolviendo cosas como las mejores prácticas ...

Sé que en los años 70 y 60 la programación era bastante diferente, por lo que no era necesario el control de revisión. Pero es en los años 80 y 90 que las personas comenzaron a usar computadoras para escribir código, y las aplicaciones comenzaron a aumentar en tamaño y alcance, por lo que me pregunto cómo las personas lograron todo eso en ese momento.

Además, ¿cómo difiere esto entre plataformas? Digamos Apple vs Commodore 64 vs Amiga vs MS-DOS vs Windows vs Atari

Nota: Estoy hablando principalmente de programación en microcomputadoras del día, no en grandes máquinas UNIX.

En primer lugar, cuando salen las microcomputadoras, el software se escribió principalmente en sistemas Unix o VMS y se compiló / ensambló en el sistema de destino. Estos sistemas informáticos eran multiusuario, a menudo con muchos terminales y tenían sistemas de control codificados como SCCS .

La conexión en red era una opción en microcomputadoras de mediados de la década de 1980, a menudo conectada a un sistema Unix como el "servidor de archivos" (tal vez solo usando RS232 y Kermit para transferir los archivos, con SCCS en el sistema Unix)

Consulte Historia de control de versiones de Eric Sink para obtener una descripción general de cómo ha cambiado el sistema de control de versiones a lo largo de los años.

Recuerdo haber leído sobre el control del código fuente en "BYTE" a fines de la década de 1980, por lo que debe haber estado en uso en "sistemas pequeños" para entonces.

SourceSafe estaba bien establecido a mediados de los años 90 ejecutándose en DOS, Windows, etc.

Este enlace muestra un artículo sobre PVCS que se ejecuta en PC desde 1994 , se encuentra en la versión 6.2, por lo que claramente ha estado presente durante algún tiempo, Wikipedia dice que data de 1985 .

Sin embargo, los disquetes numerados fueron utilizados por la mayoría de los programadores que trabajaban en software a pequeña escala hasta finales de la década de 1990, para ser reemplazados por carpetas en su disco duro, haciendo una copia del código fuente todos los días.

Recuerdo haber trabajado en un software de portabilidad de proyectos de Unit a Windows NT 3.5. Los programadores que saben programar para Windows a menudo ni siquiera habían oído hablar del control del código fuente en ese momento.

Esta línea de tiempo está tomada de una publicación de blog de codicesoftware , venden Plastic SCM, sin embargo, la descripción general de la historia de otros sistemas parece razonable, algunos sistemas más antiguos antes de que RCS quedaran fuera de la imagen.

Probablemente esto no sea representativo de la industria de juegos en general, pero funcionó bien en nuestra pequeña empresa de juegos. Nunca trabajé con software empresarial, que probablemente tenía otros requisitos.

Desde mediados de los 80 hasta mediados de los 90, a menudo usaba un número de versión al final del nombre del archivo, por ejemplo, "game.003". En aquel entonces, estaba programando el 90% en ensamblador y todo el código estaba en un solo archivo enorme, posiblemente con uno o dos incluidos, donde tenía que actualizar manualmente el número de versión a medida que las cosas cambiaban. Solo incrementaría el número después de tener una versión estable que estaba seguro de que quería mantener.

Esto eventualmente escaló un poco cómodamente a aproximadamente 3 personas. Después de eso, crecimos el equipo y terminamos teniendo un desorden de archivos por todo el lugar durante aproximadamente un año hasta que me cansé de tratar de rastrear los cambios de las personas y comenzamos a usar Perforce alrededor de 1997-98.

Tienes que ver esto en el contexto de infraestructuras comunes en ese momento. A principios de los años 80, IBM lanzó la "computadora personal" y puede tomar esto literalmente. La forma más común de desarrollar aplicaciones para una PC era un chico creando algo e intentando venderlo. Entonces, un disquete por versión lanzada probablemente sea común. Puede comprar algunas etiquetas bonitas y coloridas y escribir el nombre de su producto y la versión en él. Para la mayoría de los productos exitosos de esos días, sabías el nombre del tipo que lo escribió.

Las redes se introdujeron como complementos. Las API del cliente fueron pirateadas en DOS y las partes del servidor eran sistemas operativos dedicados y propietarios en una máquina separada. Típicamente costoso (no para las masas) y, básicamente, solo ofrece el uso compartido de archivos e impresoras. En el mundo de las PC, las cosas comenzaron a cambiar con la introducción de Windows para trabajo en grupo y Windows NT. Eso abrió muchas posibilidades. Las redes finalmente se integraron en el entorno con el que un programador estaba familiarizado y un programador de Windows podía escribir aplicaciones que pudieran comunicarse entre sí a través de la red. Este fue el final de NetWare como el sistema operativo de red dominante.

Pronto aparecieron varios sistemas de control de versiones con componentes de cliente y servidor que podría instalar fácilmente en cualquier combinación de máquinas. Con complementos para IDE y componentes de clientes que admiten opciones de línea de comandos que permitieron la integración en un sistema de compilación.

Después de que la web despegó y el acceso de PC a Internet se hizo omnipresente, se obtuvo el movimiento de código abierto y los sistemas de control de fuente basados ​​en la web. Lo curioso es que, cuando se introdujo la PC, esto se vio como un movimiento audaz de la informática centralizada a la informática distribuida. Pero la definición de central versus distribuida se ha desdibujado. ¿Es la nube la distribución definitiva o es solo la nueva computadora central monstruosa que posee toda la potencia, como solía ser la unidad central de IBM?

En los años 90 definitivamente usé software para control de versiones. Había SCCS, y el MPW de Apple tenía control de versión incorporado (Proyector). Y creo que usé Projector alrededor de 1992. En una compañía, el sistema de control de versiones era un gran armario con disquetes de cada versión, tomado una vez por semana.

Mi primer trabajo de programación de verano cuando todavía estaba de vuelta en la escuela (creo que habría sido alrededor del año 91) fue implementar un sistema automatizado de gestión de versiones y copia de seguridad para la pequeña empresa en la que trabajaba. Teníamos 3 unidades conectadas a un servidor de software, y el propietario finalmente se cansó de manejar los conflictos de versión y resolver lo que necesitaba copia de seguridad en disquetes, por lo que hicimos que los desarrolladores trabajaran en su propia PC en lugar de directamente en los archivos almacenados en el servidor como lo habían hecho hasta ahora, y escribí un sistema que mantenía todos sus archivos configurados para leer solo hasta que ejecutaban un programa que verificaba que nadie más los estaba usando, luego registraba el uso en una base de datos central de btrieve (una base de datos relacional con una consulta simple api en lugar de sql completo que se ejecutó en el servidor de software). Otro programa revisó sus cambios modificados y los copió al servidor,

Si bien este sistema fue creado a medida para la pequeña empresa en la que trabajé, imagino que muchas tiendas similares tuvieron procesos similares.

Por experiencia personal: el desarrollo en red MS-DOS de 1985 PVCS estaba disponible y era demasiado costoso. Para Apple y todas las PC que no sean MSDOS: nada. Usé T-lib ($ 50) desde 1987. Los puertos Unix (SCCS), comenzaron a filtrarse alrededor de 1990, SourceSafe alrededor de 1992.

Para 1995, si no estaba usando un VCS, no hablaba en serio.

En 1993-1995 estuve con un administrador de pensiones con 15 desarrolladores haciendo desarrollo C / C ++ en SunOS con SPARCStation 20s y Sun IPX. Nuestra base de código estaba en directorios montados en NFS. Inicialmente, estábamos haciendo versiones de copia de carpetas , pero en algún momento nos mudamos a SCCS y algunos equipos comenzaron a usar RCS .

En 1995 me mudé a otra compañía con más de 80 desarrolladores que realizan desarrollo C / C ++ en Nueva York, Londres y Hong Kong. Utilizamos ClearCase con el complemento multisitio para administrar el entorno de desarrollo.

ClearCase era bueno para sincronizar la base de código entre sitios, pero en ese momento requería casi un administrador de tiempo completo para mantener las cosas en funcionamiento. También fue mucho más lento porque ClearCase presenta archivos en un sistema de archivos virtual, con una configuración que especifica versiones de directorios y nombres de archivos con comodines basados ​​en ramas, tiempo y / o etiquetas. En un caso patológico, uno podría especificar que cada archivo individual tenga una versión diferente.