Conozco muchos sistemas de control de versiones: CVS, SVN, TFS, etc.
Busqué en Google el primer "sistema de control de revisión / control de versiones" y vi varias respuestas conflictivas.
¿Cuándo se inventó el control de fuente? ¿Quién lo inventó? ¿Como se llamaba?
version-control
history
scm
P.Brian.Mackey
fuente
fuente
Respuestas:
Aquí hay una línea de tiempo bastante decente de los principales jugadores en forma de video (sin sonido).
Sugiere que SCCS fue primero, por un margen de aproximadamente 9 años.
Sin embargo, faltan muchas cosas, como lo demuestra este blog y los comentarios resultantes.
fuente
En 1981, trabajé un trabajo de verano en Charter Information en Austin TX. Antes eran Corporación de Información Comercial de Woburn MA. Ejecutaron un Xerox Sigma 6 que se había actualizado en el campo a un Sigma 7. Usaron una cosa llamada SPUD (Actualización del programa fuente) para el control del código fuente. Estaba basado en cinta.
Rutinariamente monté la "cinta SPUD bicentenaria" y trabajé en una plataforma de mods para un código en esa cinta. Fue llamada la "cinta SPUD bicentenaria" porque fue escrita en 1976. Tenían cintas más viejas, lo que indica que SPUD se remonta más allá de 1976.
Mientras estudiaba en UT Austin (1973-1981), me topé con MODIFY y UPDATE, dos programas de control de código fuente de Control Data Corporation para CDC 6600 y mainframes posteriores. No sé cuándo salieron por primera vez, pero sospecho que salieron poco después del 6600, que (si la memoria me sirve) salió a fines de la década de 1960.
Sospecho que IBM tenía algo mucho antes que nadie, pero no tengo ningún conocimiento de la historia del mainframe de IBM, y me gusta de esa manera.
fuente
El programa IEBUPDTE , creado originalmente para el sistema OS / 360 de IBM, data de 1962, 10 años antes que SCCS . Su propósito es aplicar un conjunto de cambios a un conjunto de programas fuente de entrada, creando un conjunto de programas fuente modificados. Todo el código fuente se administró como "mazos" de tarjetas perforadas de 80 columnas o como archivos que se parecían a ellas. Estos mazos del programa fuente tenían "números de secuencia" en un conjunto fijo de columnas en cada línea o tarjeta ( COBOLespecificó que estaban a la izquierda, en las columnas 1-6, casi todo lo demás suponía que estaban a la derecha en las columnas 73-80). Los números de secuencia tuvieron que aumentar línea por línea, pero la mayoría del código fuente aumentó en 10s, 100s o 1000s, para dejar espacio en el espacio numérico integral entre dos líneas para inserciones posteriores.
Una plataforma de control típica de IEBUPDTE podría verse así:
que modificaría dos archivos de origen, "PROG001" y "PROG002", reemplazando el número de línea "5000" (a menudo la quinta línea, siguiendo la práctica "número por miles") y eliminando las líneas 9000 a 15000 en PROG001 y reemplazando la línea 92000 en PROG002 .
En su nivel más simple, esa es una definición de control de código fuente. La gente de Unix reconocería eso como lo que hace el parche , pero usando numeración explícita en lugar de implícita. Era común aplicar conjuntos de plataformas de control a un programa de entrada en secuencia, y almacenar esos conjuntos como un archivo de disco cohesivo (un conjunto de datos particionados ), que tiene una fuerte similitud con los historiales de cambios que CVS y RCS almacenan en sus
,v
archivos. IBM solía entregar parches de código llamados arreglos temporales de programa (PTF) en forma de grandes plataformas de control que modificaban archivos como parte de un conjunto de cambios relacionado, que los usuarios de Subversion y Git encontrarían familiar.fuente
IEBUPDTE
es similar apatch
.