¿Cómo funcionaban los programadores antes de que se crearan los sistemas de control de versiones?

Como muchas personas han mencionado, el período de tiempo entre la introducción de los primeros sistemas de control de versiones y el punto en el que generalmente eran de uso común incluso entre los programas profesionales es superior a treinta años. Si bien no estaba presente para los primeros sistemas de control de versiones, fui un desarrollador de código abierto activo (aunque un aficionado) durante el período en que CVS era el sistema de control de versiones dominante e incluso la mayoría de los proyectos de código abierto no usaban ninguna revisión controlar. Si bien utilicé CVS (y SVN cuando apareció) bastante para cualquier proyecto del que estaba a cargo cuando trabajaba con otros, no los utilicé para proyectos en los que era el único desarrollador, y trabajé con personas que no estaban al tanto de ellos o tenían un prejuicio contra ellos.

(De hecho, más recientemente tuve que lidiar con los resultados del código escrito por alguien que no está familiarizado con el control de revisión. En 2010, me pusieron a cargo de terminar un proyecto, de forma gratuita, que inicialmente había sido escrito por un programador de dinero con menos experiencia durante un período de 2005 a 2007. En teoría, se suponía que este proyecto estaba a dos o tres pasos menores de ser completamente funcional y ya multiplataforma; en la práctica, dependía de extensiones visuales específicas del estudio y windows.h y era poco más que una demostración, a pesar de ser treinta mil líneas de C ++ distribuidas en dos archivos y un par de miles de líneas más de python distribuidas en veinte o treinta archivos, la mitad de los cuales no se utilizaron. La mayoría de las líneas de código residían dentro de uno o más niveles de comentarios de línea, a veces fechados y con notas. La mayor parte del código de Python que fue * realmente * usado estaba en uno de una serie de archivos con la extensión ‘.txt’ y un nombre de archivo que era simplemente una fecha. implementaciones de dos o tres Las funciones muy importantes faltaban o nunca se implementaron. Existía un archivo de versiones anteriores en forma de un archivo zip que contenía cientos de otros archivos zip con fecha, pero el proceso de copia de seguridad era defectuoso y ninguno de los archivos zip contenía código fuente, solo binarios).

Hubo una cultura en la que las emisiones numeradas (incluso de los tarballs de origen) eran normales, las comunidades de desarrollo eran pequeñas si incluso excedían a una sola persona, y cualquier tipo de retroalimentación o contribución a un proyecto de código abierto era anormal. La forma normal de obtener soporte para un gran proyecto de código abierto era suscribirse a una lista de correo. Si observa sitios populares para alojar proyectos de código abierto a lo largo de los años, puede ver los restos de los mecanismos normales de desarrollo durante varios períodos en la forma en que los sitios crearon o alcanzaron una popularidad máxima durante esos períodos están estructurados; Llegué a la comunidad cerca del comienzo del ascenso de sourceforge, antes del momento en que introdujeron por primera vez el alojamiento de servidores cvs para proyectos, y cuando observa las características de los suministros de sourceforge (particularmente si observa cuándo se presentaron) puede ver una progresión de la cultura de desarrollo de código abierto de una cosa bastante solitaria a una mucho más social y orientada a las herramientas. Sourceforge tenía hosting para tarballs y listas de correo desde el principio; años después de que me inscribí por primera vez, agregaron soporte para cvs y para alojamiento web, y años después agregaron svn. Cuando apareció por primera vez el código de google, svn era dominante, y el código de google tenía wikis y svn listos para usar (con svn ocupando un lugar privilegiado incluso en comparación con las descargas de paquetes). Con github, el sistema de control de revisiones es lo primero que se ve: se va directamente al árbol de fuentes, e incluso la descripción del proyecto está debajo del pliegue, y al lado hay wikis e informes de errores realmente geniales (compárese con sourceforge, que tenía listas de correo y ‘foros’ que eran esencialmente hilos de comentarios, y durante la creación de un proyecto, el mantenedor tenía que seleccionar de un menú desplegable cuál de estas dos opciones debería informarse a los usuarios es la forma adecuada de informar errores).

También debo tener en cuenta que comencé en qbasic antes de aprender algo más, así que incluso antes de comenzar a tratar con sourceforge estaba tratando con la comunidad qbasic alrededor del período 1999-2001. http://Qbasic.com era esencialmente el único recurso de la comunidad, y el mecanismo para ser incluido en la lista era enviar un correo electrónico al único responsable del sitio. Este tipo a veces alojaba archivos BAS únicos para usted, pero de lo contrario se esperaba que los hospedara usted mismo y podría vincular a su página de proyecto. El sitio tenía un libro de visitas. Finalmente, tenía un cliente web java irc conectado a una sala de chat, que nadie usaba. Pasé mucho tiempo en ese sitio, pero nunca pude incluir mis propios programas en la lista, así que terminé alojándolos en la función de carga limitada de algún servicio gratuito de alojamiento de foros.

Hay restos de esta cultura hoy. Siento que, hasta cierto punto, el final muy aficionado del desarrollo de software todavía hace las cosas de esta manera (es decir, incluidas algunas personas extremadamente talentosas, siempre y cuando publiquen cosas solo para Windows sin fuente y lo hagan publicando hilos en foros, es decir, la mayoría de los jailbreak de teléfonos / juegos y la mayoría de las grietas de VN de importación, por nombrar algunos campos que son particularmente delincuentes graves aquí).

Cada proyecto tenía una copia maestra, generalmente bajo el control de una persona. Un “commit” era un proceso de hacer una copia de seguridad de la versión actual y luego aplicar nuevos cambios (o simplemente sobrescribir desde alguna otra copia de trabajo). Por lo general, no había un manifiesto de lo que cambiaba cada vez, por lo que si quería ver qué estaba realmente en un cambio, tendría que encontrar su predecesor y diferenciar manualmente. Los mensajes de confirmación eran comentarios en el propio código o en archivos CHANGELOG separados. Los desarrolladores individuales a menudo creaban sus propios subdirectorios, tarballs o archivos zip (dependiendo de la plataforma y la preferencia) para representar ramas o etapas de desarrollo.

Sí, todo fue muy tedioso. Sin mucho apoyo de las herramientas, se requirió más esfuerzo y diligencia de los líderes del proyecto y los ingenieros de lanzamiento (que todavía era una especialidad emergente). Los primeros sistemas de control de versiones eran realmente poco más que scripts para automatizar algunos de los procesos manuales mencionados anteriormente, sin muchos cambios en el paradigma básico. No fue hasta que RCS y SCCS introdujeron la ramificación (todavía nada como hoy) que el flujo de trabajo real realmente comenzó a cambiar.

Ah, los buenos tiempos…

Cuando llegué a los sistemas UNIX, SCCS estaba fácilmente disponible si rara vez se usaba, y RCS apareció en el ’82, lo cual fue una gran mejora. (La diferencia básica era que SCCS mantuvo el código original y todos los diferenciales que se acumularon hasta la base actual, y RCS mantuvo la base actual y todos los diferenciales que lo regresaron al origen).

Sin embargo, tuve que lidiar con un montón de cosas en los mainframes de IBM, varios sistemas operativos DEC y, por supuesto, una tonelada de sistemas integrados.

En los mainframes de IBM, como Drew mencionó, las cajas de tarjetas perforadas dominaron el día en algunas tiendas, pero los repositorios de código en las bibliotecas en línea eran mucho más la norma. Había un tipo de archivo que contenía módulos de binarios enlazables, a los que se hacía referencia mediante una declaración “SYSLIB” del sistema operativo (muy parecido al enlace UNIX con la convención “-lfoo”). Había una estructura correspondiente para el código fuente y una forma de construir bibliotecas binarias a partir de bibliotecas fuente. Por desgracia, todos los detalles se pierden en los recovecos más profundos de mi mente …

Como dice Jeff, había alguien que “poseía” el código, y si se le asignara una parte del mismo, normalmente un procedimiento o llamada de función con una referencia externamente enlazable, le entregarían una copia del código. haga su trabajo, comente cuidadosamente a medida que avanza y devuélvalo. En un mundo ideal, la funcionalidad del “recuadro negro” no cambió, por lo que la documentación general seguía siendo la misma, solo se modificaron las partes internas (generalmente para mantener el código funcionando en función de algún cambio en el sistema operativo o un cambio de biblioteca de terceros) )

Si su código pasó la prueba de regresión, el propietario vería lo que hizo, y si su código cumple con los estándares y los comentarios son aceptablemente informativos, generalmente realiza un reemplazo total de la versión anterior con la nueva versión, manteniendo N versiones anteriores ” por si acaso”.

Fue tedioso. Y efectivamente evitó que más de una persona trabajara en el mismo fragmento de código al mismo tiempo, lo que promovió la descomposición del código en piezas mucho más granulares.

Los sistemas DEC (RT-11, RSX-11, VMS) tienen funciones similares, algunas más UNIX que otras. Usaste el mismo tipo de metodología: obtén acceso a una copia de la fuente del Codemeister (¡hey, así es como los llamamos!), Trabaja en ello, obtén tu prueba de aprobación del código, asegúrate de que los comentarios sean lo suficientemente buenos, mano vuelva a entrar, espero que no sea enviado de vuelta para volver a trabajar.

Si eras una banda de un solo hombre, por supuesto, no había disciplina. Hasta la primera vez que te quemaste. Entonces, por lo general, tenía una biblioteca de disquetes llena de versiones anteriores de su código “por si acaso” …

Oh chico. Solía ​​trabajar en un software de contabilidad. (Navision, ahora propiedad de Microsoft y rebautizada como MS Dynamics Nav.) Todo el código se almacenó (y aún así, si no me equivoco) como BLOB o similar dentro de la base de datos, y los clientes son, por supuesto, solo de Windows. Recuerdo vívidamente cuándo tuvimos que hacer una actualización de versión en todos nuestros proyectos. Exportamos todo el código como texto, función por función, luego lo distribuimos a través de un elegante editor de ventanas y volvimos a aplicar todos nuestros cambios a una base de datos (es decir, base de código) en la versión más reciente. Dos personas estaban sentadas una al lado de la otra para llevar a cabo esa rutina tediosa, destructora del cerebro y larga, que una computadora podría haber manejado miles de millones de veces mejor.

Teníamos nuestra propia pequeña convención para los comentarios del código fuente que requería que siempre comentaras el código original y dejaras tu nombre de usuario y fecha más algún comentario. Ooooh chico, era un gran desastre, pero era la única oportunidad de saber de alguna manera lo que estaba pasando. Y, en comparación con nuestra competencia, ¡avanzamos en nuestros intentos de controlar las versiones!

En aquel entonces, ninguno de nosotros sabía que los VCS eran una cosa, así que no nos molestamos. En realidad, fue una especie de gran espectáculo, trabajar en estrecha colaboración con un colega mucho más experimentado y hacer una tarea bastante mecánica en lugar de codificar soluciones novedosas que podrían hacer o deshacer una empresa.

Me llevó unos 3 años más descubrir svn, y luego tal vez 3 años más para entrar en git y darme cuenta de por qué los VCS son tan increíbles. En estos días, ni siquiera comienzo un proyecto (completamente independientemente del tamaño o el contenido) sin hacer primero un git init . Me he acostumbrado tanto que ni siquiera estoy seguro de saber cuántos problemas me ahorra.

Generalmente usaban tarjetas perforadas donde los cambios eran objetos físicos.

SCCS se lanzó por primera vez en 1972, hace 42 años, anterior a muchas de las herramientas que la gente usa a menudo en lugar del software de control de versiones como los archivos zip introducidos en la década de 1980 y difiere del programa homónimo enviado en 1974.

El control de fuente incluso es anterior a los terminales CRT que se están volviendo populares como el ADM-3A de 1975 y el VT100 de 1978.

Desafortunadamente, como el comentario de Jeff Darcy sugiere que la gente tardó en adaptarse.

En el momento en que tomé las Estructuras de datos en el año escolar 1991-1992, los estudiantes reprobaron el curso si no usaban repositorios RCS de los cuales el sistema de calificación basado en pruebas de unidad automatizada de los asistentes de enseñanza verificó el código.

Algunas organizaciones tardaron más en llegar al programa.

La gente se volvió muy buena en diff y patch, al menos en proyectos públicos.

el parche aplica diferencias al código fuente. Es inteligente tratar de encontrar un lugar para poner un parche si ha habido otros cambios en el código. Puede agregar una línea o restar una línea aquí o allá, pero lo que no puede hacer es reformatear al por mayor el código fuente. Si haces eso, tus parches no se aplican, y no tienes que regresar y arreglar las cosas a mano.

Las grandes distribuciones de software en comp.sources.unix de Usenet no se redistribuirían en su totalidad. Por el contrario, alguien propondría un parche y lo distribuiría, y si hiciera lo que se suponía que hiciera, podría redistribuirse como un parche. Cuando se acumulan muchos parches, se pueden consolidar en un “parche gigante” que puede hacer cambios sustanciales al original.

Algunos proyectos se desmoronaron porque no había nadie en un papel central que fuera bueno para realizar un seguimiento de los parches, o no tomaría los parches que la gente quería.

Todo esto comenzó a cambiar cuando Internet hizo posible enviar distribuciones completas (como parcheadas), pero aún hubo demanda de parches siempre que algunas personas estuvieran en enlaces lentos o solo por correo electrónico.

Antes de Git, había Perforce, PlasticSCM, Subversion, CVS, RCS, Mercury, SCCS y muchos otros.

Antes de que existiera cualquier sistema de control de revisiones, los equipos trabajaban en diferentes partes del software. Los cambios se distribuyeron a través de parches en formato diff unificado. Los conjuntos de parches se recopilaron a medida que la gente pensaba en ello, y luego se produjo una nueva construcción. Incluso en la era del control de software, los proyectos complejos a menudo circulaban con docenas de archivos de parche. X11R4 y OpenLook están marcados para siempre en mi memoria.

Copia de seguridad personal y comparación de archivos. Aquí hay más detalles.

Así es como hemos estado haciendo software embebido para Intel 8080/8085 en el equipo de la Unión Soviética, se hizo una copia maestra y una sola persona se dedicó a fusionar nuevos cambios y hacer copias de seguridad. Cada ingeniero comenzó su propio código fuente desde el clon de la copia maestra y luego está solo con sus copias de seguridad. Una vez que haya terminado con su función, se fusionará nuevamente en la copia maestra. La fusión se ha realizado mediante un software de combinación / comparación muy similar al que tenemos ahora. Recuerdo haber hecho esto en CP / M OS CP / M – Wikipedia. La misma computadora basada en CP / M se ha utilizado para soportar EPROM EPROM – Programación, lectura y comparación de código binario de gestión de Wikipedia.

Siempre hubo un historial de versiones anteriores de archivos.
No siempre completo y fusionado, pero generalmente toda la historia.
Entonces, si se pierde algún código durante la fusión de una versión manual, podría encontrarse.

Las copias de seguridad diarias, las copias de seguridad semanales en cinta magnética y los disquetes eran la norma.
Sí, podría perder uno o dos días de trabajo, pero era inteligente y siempre podía repetir el trabajo incremental perdido al inspeccionar manualmente las copias de seguridad.
En el peor de los casos, perdiste una semana.
Ahora, si las copias de seguridad fallaron o se perdieron, entonces alguien recibiría un disparo.
Con suerte, los técnicos de TI probaron las copias de seguridad cada pocas semanas.

Al leer las otras respuestas aquí, parece que todos tenían sus propias
“sistema”, así que pensé que contribuiría con uno que me presentaron a finales de los 90 como desarrollador web recién creado …

Trabajé para un par de compañías más pequeñas donde era una práctica estándar conectarse directamente a través de ssh al servidor y editar archivos php directamente.

Esto funcionó un poco ya que solo había 2-5 personas trabajando en las aplicaciones y, a menudo, trabajaban en diferentes secciones de los sitios, incluso para que la gente gritara en la oficina en qué archivos estaban trabajando. Creo que nunca digo colisiones, pero estoy seguro de que hubo algunas.

Si alguien estuviera trabajando en un proyecto más grande, copiarían todo el directorio en un subdirectorio y trabajarían en esos archivos. Cuando finalizara el proyecto, volverían a copiar los archivos modificados en el directorio principal.
El sistema estaba lleno de directorios llamados new / new2 / new3 / old /.

Permítanme decir que esta fue una forma terrible de trabajar, es un milagro que el sistema funcionó y no introdujimos ningún error grave ni afectamos el servicio para los clientes.

Acabamos de compartir tarballs y archivos diff. Los equipos de programación eran más pequeños y los sistemas también eran más pequeños. Era torpe pero manejable. Intentamos asegurarnos de trabajar en partes realmente diferentes del sistema y la filosofía * nix de aplicaciones discretas de un solo propósito ayudó. Y si. ¡La fusión fue un DOLOR! Ese era el trabajo del bibliotecario.

Ah, sí, en el pasado, la última mitad de los ochenta para ser exactos.

Trabajamos con mucho cuidado.

Solo teníamos una versión de nuestro árbol de origen y si se informaba un error en una versión anterior mientras estábamos en medio de un cambio importante, teníamos que esperar hasta que se hiciera antes de buscar el error, sin importar cuán crítico sea ese error estaba. No había forma de almacenar la versión actual ni volver a una versión anterior.

Luego tenemos una pequeña caja UNIX con SCCS.

Ponemos todo nuestro código en SCCS y desde entonces podríamos atacar los errores en cuestión de horas en lugar de días. A nuestro personal de apoyo realmente le gustó eso. Desde entonces, he creído firmemente en el uso de la gestión de la configuración; no trabajaré sin él.

Utilizamos otros sistemas de control de versiones o intercambio de archivos.