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

De wiki EOI de documentación docente
Saltar a: navegación, buscar
Línea 25: Línea 25:
 
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:
 
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:
  
+
<pre>
 
    cvs -d:pserver:anonymous@progs.org:/var/lib/cvs co mod  
 
    cvs -d:pserver:anonymous@progs.org:/var/lib/cvs co mod  
 
+
</pre>
  
 
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:
 
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:
  
+
<pre>
 
    cd mod
 
    cd mod
 
    ./configure
 
    ./configure
Línea 37: Línea 37:
 
    make install
 
    make install
 
             ...
 
             ...
 
+
</pre>
  
 
Cuando quiere una nueva versión, simplemente actualiza su copia dentro de mod.
 
Cuando quiere una nueva versión, simplemente actualiza su copia dentro de mod.
  
 +
<pre>
 
    cd mod  
 
    cd mod  
 
    cvs update  
 
    cvs update  
Línea 47: Línea 48:
 
    make install
 
    make install
 
    ...  
 
    ...  
 
+
</pre>  
  
 
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):
 
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):
  
+
<pre>
    cvs diff -ubB | mail -s "Mis parches" mod-maint@progs.org
+
    cvs diff -ubB
 
+
</pre>
 +
|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=
 +
}}{{Apartado
 +
|Tipo bloque contenido=Encabezado + bloque de texto
 +
|Título apartado=Otros sistemas de gestión de fuentes
 +
|Número apartado=2
 +
|Contenido=CVS, a pesar de ser el sistema de control de versiones más ampliamente usado, tiene notables inconvenientes:
  
El desarrollador normal
+
:Nota: En 2007 Subversion es ya claramente el sucesor de CVS, y muchos desarrollos de software libre han migrado a él.
  
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.
+
* No soporta renombrados o cambios de directorio de ficheros, ni tampoco metadatos (propietarios, permisos, etc.) ni enlaces simbólicos.
Nota
+
  
Por seguridad, para cuentas con derecho a escritura, se suele usar ssh, que proporciona un canal autenticado y cifrado.
+
* 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.
  
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í:
+
* 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 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.
+
* 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.
  
¿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.
+
* CVS no genera, sin la ayuda de herramientas aparte, el fichero changelog, que muestra la historia global de cambios de un proyecto.
  
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.
+
* CVS no soporta bien proyectos con un número muy grande de ficheros, como es el caso del núcleo de Linux.  
  
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:
+
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.
  
$Id: parte.c,v 1.7 2003/07/11 08:20:47 joaquin Exp $
+
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.
  
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).
+
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]).
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=
 
|Archivo=
 
|Ancho archivo=
 
|Ancho archivo=
Línea 115: Línea 136:
 
|Archivo vídeo 4=
 
|Archivo vídeo 4=
 
|Pie vídeo 4=
 
|Pie vídeo 4=
 +
}}{{Apartado
 +
|Tipo bloque contenido=Encabezado + bloque de texto y columna lateral
 +
|Archivo=
 +
|Ancho archivo=
 +
|Pie archivo=
 +
|Identi vídeo 1=
 +
|Archivo vídeo 1=
 +
|Identi vídeo 2=
 +
|Archivo vídeo 2=
 +
|Identi vídeo 3=
 +
|Archivo vídeo 3=
 +
|Identi vídeo 4=
 +
|Archivo vídeo 4=
 
}}
 
}}
 
|Estado=esbozo
 
|Estado=esbozo

Revisión del 01:02 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


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]).


Imágenes y recursos

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

Sección siguiente >
Documentación