Diferencia entre revisiones de «Gestión de fuentes en Software libre»

De wiki EOI de documentación docente
Saltar a: navegación, buscar
(Página creada con «{{Sección |Título=Gestión de fuentes |Libro=Software libre |Capítulo=Entornos y tecnologías de desarrollo |Número sección=5 |Introducción=A todo proyecto de desarro...»)
 
Línea 6: Línea 6:
 
|Introducción=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.
 
|Introducción=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.  
+
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.
|Apartados=
+
|Apartados={{Apartado
 +
|Tipo bloque contenido=Encabezado + bloque de texto
 +
|Título apartado=CVS
 +
|Número apartado=1
 +
|Contenido=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:
 +
 
 +
<pre>
 +
    cvs -d:pserver:anonymous@progs.org:/var/lib/cvs login
 +
</pre>  
 +
 
 +
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 | mail -s "Mis parches" mod-maint@progs.org
 +
 
 +
 
 +
El desarrollador normal
 +
 
 +
El desarrollador normal tendrá una cuenta en el servidor. Puede usar el mismo mecanismo y protocolo que el usuario anónimo, cambiando anonymous por el nombre de su cuenta.
 +
Nota
 +
 
 +
Por seguridad, para cuentas con derecho a escritura, se suele usar ssh, que proporciona un canal autenticado y cifrado.
 +
 
 +
Una vez tiene una copia de trabajo del módulo, puede hacer las modificaciones necesarias y, cuando considere que se han estabilizado, comprometer los cambios en el repositorio. Por ejemplo, si modifica los ficheros parte.h y parte.c, los comprometerá así:
 +
 
 +
 +
    cvs ci parte.h parte.c
 +
 
 +
 
 +
Antes de terminar la operación, el CVS nos pedirá una explicación de lo que se hizo, que se adjuntará al historial de ambos ficheros. Así mismo incrementará el número de revisión de cada fichero en una unidad. Este número identifica cada momento importante en la historia de un fichero y puede usarse para recuperar cada uno de esos momentos.
 +
 
 +
¿Cuando debe un desarrollador realizar una operación de compromiso? Esta es una cuestión metodológica que deben acordar los miembros de un proyecto, pero parece obvio que no deben comprometerse cambios que no compilen. Pero es preferible además pasen una batería de pruebas mínima. En muchos proyectos es además necesario contar con la aprobación de un supervisor de proyecto o subproyecto que examine la modificación.
 +
 
 +
Durante el desarrollo de la modificación, alguien puede haber alterado otros ficheros, o incluso los mismos. Por ello conviene que el desarrollador haga, con relativa frecuencia, una operación de actualizar su copia (cvs update). Si han modificado otros ficheros, puede haber cambiado el entorno y fallar pruebas que antes pasaban. Si han modificado los mismos ficheros, puede ser en lugares o rutinas que no hemos tocado o en código que sí hemos modificado. En el primer caso no hay conflicto (al menos aparente) y la operación de modificación mezcla nuestra versión con la del repositorio, generándose ficheros combinados, con todas las modificaciones. En caso contrario hay conflicto, en cuyo caso hay que ponerse de acuerdo con el desarrollador que hizo los otros cambios y acordar una versión final.
 +
 
 +
Para mejor identificar cada componente de un proyecto, es conveniente que lleve asociada directamente información de revisión. CVS puede marcar los fuentes y los objetos automáticamente, siempre y cuando observemos cierta disciplina. Por ejemplo, si en un comentario del fuente escribimos la palabra clave $Id$, cada vez que el fichero se comprometa en el repositorio, dicha palabra se sustituirá por una cadena de identificación, donde podemos ver nombre de fichero, número de revisión[8], fecha y hora del compromiso y autor del mismo:
 +
 
 +
$Id: parte.c,v 1.7 2003/07/11 08:20:47 joaquin Exp $
 +
 
 +
Si esa palabra clave la incluimos dentro de una cadena de caracteres del programa, al compilarlo la cadena aparecerá en el objeto y el ejecutable, con lo que es posible identificarlo con una herramienta (ident).
 +
El administrador
 +
 
 +
Obviamente los administradores son los que tienen y deben llevar la parte más complicada del mantenimiento del repositorio. Por ejemplo, tienen que dar de alta el proyecto, dar permisos a los desarrolladores y coordinarlos, etiquetar versiones entregadas, etc.
 +
 
 +
Es práctica común que todo proyecto tenga una versión estable y otra experimental. Para ello se crean ramas. Mientras que los que se dedican al mantenimiento corrigen errores de la rama estable, los nuevos desarrollos se hacen sobre la rama experimental. Cuando ésta se estabiliza, hay que pasarla a estable, no sin antes aplicar las correcciones hechas sobre la rama estable anterior. Esta operación se llama mezclar, es delicada, y está soportada en CVS, aunque de forma algo primitiva. Esta idea puede extenderse al concepto de ramas experimentales evolucionando en distintas direcciones, llegando o no a buen puerto, que en todo caso, a menos que sean vías muertas, habrá que integrar total o parcialmente en el producto estable, con mezclas apropiadas.
 +
 
 +
Un derecho que nos da el software libre es modificar un programa para uso privado. Aunque es deseable contribuir con toda mejora al acervo comunitario, muchas veces las modificaciones que queremos hacer son demasiado específicas y no interesan al público en general. Pero sí nos interesa incorporar la evolución del programa original. Esto puede realizarse con un tipo especial de ramificación y mezcla (ramas de vendedor).
 +
 
 +
El administrador también puede facilitar la coordinación del equipo por medio de mecanismos automáticos, como hacer que se produzcan mensajes de correo electrónico cuando ocurran ciertas cosas, como los compromisos. O forzar a que se realicen ciertas acciones automáticas antes de realizar un compromiso, como comprobaciones automáticas de estilo, compilaciones o pruebas.
 +
|Archivo=
 +
|Ancho archivo=
 +
|Pie archivo=
 +
|Archivo 1=
 +
|Pie archivo 1=
 +
|Archivo 2=
 +
|Pie archivo 2=
 +
|Archivo 3=
 +
|Pie archivo 3=
 +
|Archivo 4=
 +
|Pie archivo 4=
 +
|Servidor vídeo 1=
 +
|Identi vídeo 1=
 +
|Archivo vídeo 1=
 +
|Pie vídeo 1=
 +
|Servidor vídeo 2=
 +
|Identi vídeo 2=
 +
|Archivo vídeo 2=
 +
|Pie vídeo 2=
 +
|Servidor vídeo 3=
 +
|Identi vídeo 3=
 +
|Archivo vídeo 3=
 +
|Pie vídeo 3=
 +
|Servidor vídeo 4=
 +
|Identi vídeo 4=
 +
|Archivo vídeo 4=
 +
|Pie vídeo 4=
 +
}}
 
|Estado=esbozo
 
|Estado=esbozo
 
}}
 
}}

Revisión del 00:55 28 feb 2012


Estado de desarrollo de la sección: esbozo 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

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

Sección siguiente >
Documentación