Gestión de fuentes en Software libre

Estado de desarrollo de la sección: esbozo Wikilibro: Software libre > Capítulo 7: Entornos y tecnologías de desarrollo

Sección 5

Gestión de fuentes

A todo proyecto de desarrollo de programas le conviene tener archivada la historia del mismo. Por ejemplo, porque alguna modificación pudo producir un error oculto que se descubre tardíamente y hay que recuperar el original, al menos para analizar el problema. Si el proyecto lo desarrollan varias personas, es necesario también registrar el autor de cada cambio, con las razones del mismo explicadas. Si del proyecto van haciéndose entregas versionadas, es necesario saber exactamente que versiones de cada módulo forman dichas entregas. Muchas veces, un proyecto mantiene una versión estable y otra experimental; ambas hay que mantenerlas, corregir sus errores, y transferir errores corregidos de una versión a la otra. Todo esto puede hacerse guardando y etiquetando convenientemente todas y cada una de las versiones de los ficheros, lo que generalmente se ha considerado como un costo excesivo, aunque con los discos actuales empiece a no ser tan cierto. Lo que normalmente hace un sistema de control de fuentes, también llamado sistema de gestión de versiones, es registrar la historia de los ficheros como un conjunto de diferencias sobre un patrón, normalmente el más reciente, por eficiencia, etiquetando además cada diferencia con los meta-datos necesarios. Pero también queremos que un sistema de estos sirva para que muchos programadores colaboren efectivamente, sin pisarse el trabajo, pero sin detener el avance de cada uno. Debe permitirnos pues que haya varios programadores trabajando concurrentemente, pero con un cierto control. Este control puede ser optimista o pesimista. Con un control pesimista, un programador puede reservarse unos ficheros para una mejora durante un tiempo, durante el cual nadie puede tocar estos ficheros. Eso es muy seguro, pero bloqueará a otros programadores y el proyecto puede retrasarse, sobretodo si el que bloqueó los ficheros está ocupado en otras cosas, o incluso se olvidó de ellos. Permitir a otros avanzar es más dinámico, pero más peligroso, ya que puede haber modificaciones incompatibles. Un sistema optimista deja avanzar, pero nos avisa cuando ha habido conflictos y nos proporciona herramientas para resolverlos.

CVS CVS (Concurrent Version Sytem) es un sistema de gestión de fuentes optimista diseñado a finales de los 80, que es usado por abrumadora mayoría en los proyectos libres[cvshome][fogel:cvs][ceder:cvs]. Utiliza un repositorio central al que se accede según un sistema cliente/servidor. El administrador del sitio decide quienes tienen acceso al repositorio o a qué partes del repositorio, aunque normalmente, una vez que un desarrollador ha sido admitido en el círculo de confianza, tiene acceso a todos los ficheros. Además puede permitirse un acceso anónimo, sólo en lectura a todo el mundo. El colaborador anónimo El CVS anónimo es una herramienta fundamental para realizar el concepto de entregar pronto y frecuentemente defendido por Eric Raymond. Cualquier usuario ansioso de probar la última versión de un programa la puede extraer del CVS, descubrir errores y reportarlos, incluso en forma de parches con la corrección. Y puede examinar la historia de todo el desarrollo. Veamos un poco de mecánica. Un usuario avanzado quiere obtener la última versión del módulo mod de un repositorio accesible anónimamente en progs.org, directorio /var/lib/cvs y protocolo pserver. La primera vez declarará su intención de acceder: cvs -d:pserver:anonymous@progs.org:/var/lib/cvs login Nos pide una contraseña, que será la del usuario anónimo (normalmente retorno de carro), que se registrará en un fichero local (realmente esta operación no es necesaria para acceso anónimo, pero el programa se queja si no existe el fichero con la contraseña). Seguidamente, lo importante es obtener la primera copia del módulo: cvs -d:pserver:anonymous@progs.org:/var/lib/cvs co mod Esto creará un directorio mod con todos los ficheros y directorios del módulo y ciertos meta-datos (contenidos en subdirectorios llamados CVS), que nos permitirán, entre otras cosas, no tener que repetir la información ya dada. Nuestro usuario avanzado se introduce en el directorio creado, genera el paquete, y prueba: cd mod ./configure make make install ... Cuando quiere una nueva versión, simplemente actualiza su copia dentro de mod. cd mod cvs update ./configure make make install ... Si resulta que descubre un error, puede corregirlo en el sitio y luego mandar un parche por correo electrónico al mantenedor del programa (individual o lista de correo): cvs diff -ubB

Otros sistemas de gestión de fuentes CVS, a pesar de ser el sistema de control de versiones más ampliamente usado, tiene notables inconvenientes: Nota: En 2007 Subversion es ya claramente el sucesor de CVS, y muchos desarrollos de software libre han migrado a él. No soporta renombrados o cambios de directorio de ficheros, ni tampoco metadatos (propietarios, permisos, etc.) ni enlaces simbólicos. Al ser una evolución de un sistema de control de versiones de ficheros individuales, no soporta naturalmente el control de versiones de grupos completos. No soporta conjuntos de cambios coherentes. En efecto, para añadir una característica o corregir un error, puede ser preciso cambiar varios ficheros. Estos cambios deberían ser atómicos. En CVS es bastante complicado el uso de ramas y mezclas. En efecto, si creamos una rama experimental de un proyecto, y deseamos incluir las correcciones hechas a la rama estable, es preciso conocer en detalle que correcciones se han hecho ya, para no hacerlas varias veces. CVS depende de un servidor centralizado y, aunque puede hacerse trabajo estando desconectado, necesitamos conexión con el mismo para generar versiones, compararlas y mezclarlas. CVS no genera, sin la ayuda de herramientas aparte, el fichero changelog, que muestra la historia global de cambios de un proyecto. CVS no soporta bien proyectos con un número muy grande de ficheros, como es el caso del núcleo de Linux. Y sin embargo existen otros sistemas libres que solucionan varios de estos problemas. Podemos destacar el ya designado sucesor de CVS: subversion[subversion][ora:subversion], que resuelve estrictamente los problemas básicos de CVS y puede utilizar extensiones de HTTP (WebDAV) para soslayar políticas de seguridad agresivas. El modelo de desarrollo basado en un repositorio centralizado, aunque apto para el trabajo cooperativo, no satisface todas las espectativas, ya que por un lado depende de la accesibilidad y buen funcionamiento del servidor, y por otro depende de los administradores de ese servidor el que podamos crear nuestras propias ramas de desarrollo. A veces se desean repositorios distribuidos que permitan a cualquiera tener un repositorio con una rama privada o pública que luego puede mezclar o no con la oficial. Así funcionan GNU arch[arch] o bazaar[bazaar], así como sistema propietario BitKeeper[bitkeeper], elegido por Linus Torvalds para mantener Linux desde febrero de 2002, ya que según él no había ninguna herramienta libre apropiada. Se dice que el uso de Bitkeeper dobló el ritmo de desarrollo de Linux. No obstante la decisión fue muy criticada por ser propietario, con una licencia que permitía a los proyectos libres obtenerlo gratuitamente siempre que todas las operaciones de compromiso de cambios con sus meta-datos se registren en un servidor público designado por los propietarios y accesible a todo el mundo, y siempre que el licenciatario no desarrollara otro sistema de control de fuentes que pudiera competir con él. Fue precisamente el intento de desarrollar un producto libre compatible por parte de un empleado de la misma empresa donde trabajaba Linus Torvalds el detonante del cambio de sistema de gestión de fuentes. Linus desarrolla rápidamente un sustituto provisional, git[git], que pronto se convierte en definitivo, donde se condensa toda la experiencia en el desarrollo cooperativo y descentralizado de Linux: soporta proyectos de gran tamaño de forma descentralizada, facilitando grandemente el desarrollo de ramas tentativas y su mezcla con otras o con la principal, con mecanismos de seguridad criptográficos que impiden alterar el historial. A partir de abril de 2005 Linux se mantiene con git o envoltorios del mismo (por ejemplo, cogito[cogito]).

< Sección anterior Mecanismos básicos de colaboración

Sección siguiente > Documentación