Documento de Configuración del Control de Versiones sobre PICS David Ortega y Jorge A. Beltrán Carrera de Ingeniería de Sistemas Universidad Javeriana Bogotá, Colombia {david.ortega, jnull}@javeriana.edu.co Para la consecución de nuestro segundo objetivo: “Implementar el manejo de versiones dentro del repositorio”, hemos hecho una búsqueda en el campo de la administración de versiones de software para tomar la decisión más acertada respecto al sistema que será implementado y como serán las políticas que se apliquen. En el documento publicado sobre el estado del arte se hace un breve acercamiento a la importancia que tiene para cualquier desarrollador el control de cada una de las versiones de un proyecto, es por esto que presentamos a continuación las normativas que se tendrán en cuenta en adelante a nivel de versiones en el repositorio. 1. Esquema de control Lo primero que haremos antes de revisar la forma en que estamos controlando las versiones es mirar el contexto del problema para asegurarnos que mediante la implantación del sistema cubrimos las áreas más importantes. Encontramos que el control de versiones de nuestro sistema se debía desarrollar bajo dos ambientes distintos, por un lado el que concierne al desarrollo, mientras por el otro lado el de implantación del sistema. El desarrollo del sistema se refiere a los cambios que se generan mientras el sistema se esta construyendo, por lo que obedece tanto a la configuración en si del mismo, como a la que se genera de acuerdo a los documentos que acompañan este avance. Por el otro lado se presenta el ambiente de implantación del sistema definido por todos y cada uno de los componentes, independiente de su estructura, que se suban al sistema para ser puestos a disposición de los usuarios. Esta subdivisión nos permite clarificar un poco mejor los actores que participan en cada uno de los ambientes y definir los roles que se manejan en el control de versiones del proyecto. En el primer ambiente es necesario que los desarrolladores tengan acceso total tanto al proyecto como a los documentos generados, de tal forma que los avances que cada uno de nosotros pueda aportar queden registrados inmediatamente en el desarrollo del proyecto, es por esto que los desarrolladores ofician como administradores del sistema con todos los permisos garantizados, en caso de conflicto, cada uno de los desarrolladores está en capacidad de decidir que cambios se quedan y cuales no. Para este ambiente en particular no parece hacer falta la definición de usuarios de solo lectura ya que además de los actores previamente mencionados, el control de versiones no será manipulado por nadie más. Por el lado del ambiente de implantación del sistema se destaca la participación de los usuarios del sistema, serán ellos los encargados de llevar el control de sus propios cambios ya que es verdaderamente difícil llevar un control línea a línea de lo que suben una cantidad considerable de usuarios. La presentación de los avances y en general la manipulación que se le dará a las versiones se orientará a revisiones, lo cual significa que el modelo de control estará preocupado por los avances que presenta el área de desarrollo y que interesan de manera directa al grupo interno más que a los agentes externos. Esta decisión refleja de cierta forma lo nombrado anteriormente con respecto a que el ambiente de implantación tendría un control de versiones mucho más liviano que el del ambiente de desarrollo. La nomenclatura definida para el manejo de nuestras versiones de trabajo estará compuesta por dos identificadores, en donde el primer número señalará los lanzamientos, mientras el siguiente número será el asignado a la revisión de la cual es objeto el documento. Sentimos que de acuerdo a la definición del manejo que se le dará al proyecto, el esquema presentado es suficiente. 2. Definición de requerimientos funcionales y no funcionales Actualización de versiones: La evolución del trabajo debe ser registrada constantemente para evitar la pérdida de información valiosa, por lo que se hace necesario la actualización de versiones. Montaje y desmontaje de copias: Así como existen documentos que se mantienen dentro del proyecto desde el principio hasta el final, existen igualmente documentos que en un momento pueden ser desechados definitivamente ya que no aportan nada al desarrollo, es entonces cuando se acude al desmontaje de copias. Congelado y descongelado: Las funciones de congelado y descongelado nos permiten bloquear un documento que se encuentra en cambio y que por alguna razón no puede ser liberado para que otros usuarios lo trabajen. Solución de conflictos: La solución de conflictos se aplica a todas las ocasiones en que los desarrolladores intentan modificar concurrentemente las mismas líneas de código en los mismos archivos. Esperamos que esta situación se produzca en baja cuantía. Mecanismos de documentación: Debido a la importancia mencionada anteriormente acerca del control de versiones, se hace necesario que todo lo que se haga en este tema quede perfectamente documentado. Movimiento dinámico de archivos y directorios: Esta propiedad nos permite cambiar el lugar de acceso de los archivos que tengamos en un controlador ya sea por su ruta o por su nombre en particular. Control de acceso: El control de acceso nos permite asegurar que somos nosotros quienes realmente nos conectamos y garantizamos no perder información a causa de ingresos no permitidos. Control de cambios detallados línea a línea: Cada cambio que se haga debe estar correctamente identificado de tal forma que sea fácil el mapeo de las versiones a un estado general del proyecto. 3. Alternativas Existen en el mercado una cantidad creciente cada una procurando agregar algún tipo específico de funcionalidad, las más populares son: CVS, Aegis, Arch, Bit Keeper, CmSynergy, Co-Op, Darcs, Monotone, OpenCm, Perforce, PureCM, Subversión, Superversión, svk, Vesta y Visual Source Safe (La versión de Microsoft). 4. Decisión Últimamente uno de los CSV mas renombrados ha sido Subversión, ya que se ha considerado una evolución interesante del clásico CVS. Su punto de partida fundamental fue la corrección de aquellos errores de diseño que aparentemente habían condenado a CVS a sufrir de fallos sin solución, de tal suerte que el grupo CollabNet se puso a la tarea de recopilar los reportes de errores generados por CVS y desarrollar Subversión, actualmente algunos de los avances más notables por parte de Subversión son: Desarrollo de transacciones verdaderamente atómicas, cambio dinámico de nombre de directorios y archivos, búsqueda por meta datos, mayor interoperabilidad debido a su poder de comunicación a través del protocolo WebDAV basado en http, los costos son proporcionales a los cambios, no al tamaño de los datos, persistencia en archivos planos o bases de datos (BerkeleyDB) y eficiencia igualada tanto para archivos planos como para archivos binarios. 5. Descripción de Subversión Las características más importantes de este CSV las transcribimos a continuación tal cual aparecen en el svnbook, que es el documento oficial del sistema. En la página: http://www.subversion.tigris.org se encuentra el siguiente texto. 5.1. Que es Subversión? Subversion es un sistema de control de versiones libre/código fuente abierto. Esto es, Subversion maneja ficheros y directorios a través del tiempo. Hay un árbol de ficheros en un repositorio central. El repositorio es como un servidor de ficheros ordinario, excepto porque recuerda todos los cambios hechos a sus ficheros y directorios. Esto le permite recuperar versiones antiguas de sus datos, o examinar la historia de cómo han cambiado (sus datos). En este aspecto, mucha gente piensa en los sistemas de versiones como en un tipo de “máquina del tiempo”. Subversion puede acceder a su repositorio a través de redes, lo que permite ser usado por la gente desde distintos ordenadores. En cierto modo, la capacidad para que varias personas puedan modificar y administrar el mismo sistema de datos desde sus respectivas localizaciones fomenta la colaboración. Se puede progresar más rápidamente sin un único conducto por el cual deban pasar todas las modificaciones. Y como el trabajo está en versiones, no debe temer que la calidad sea la compensación por la pérdida de ese conducto—si se ha hecho un cambio incorrecto a los datos, simplemente deshaga ese cambio. Algunos sistemas de control de versiones también son sistemas de administración de configuración de software. Estos sistemas son creados específicamente para la administración de árboles de código fuente, y tienen muchas características que son específicas del desarrollo de software— tales como el entendimiento nativo de lenguajes de programación, o el suministro de herramientas para la construcción de software. Sin embargo, Subversion no es uno de estos sistemas. Subversion es un sistema general que puede ser usado para administrar cualquier conjunto de ficheros. Para usted, esos ficheros pueden ser código fuente— para otros, cualquier cosa desde la lista de la compra de comestibles hasta las combinaciones de vídeo digital y más allá. 5.2. Características de Subversion Al discutir acerca de las características que Subversion aporta al mundo del control de versiones, es a menudo útil hablar de ellas en términos de cómo han mejorado sobre el diseño de CVS. Si no está familiarizado con CVS, puede no entender todas estas características. Subversion proporciona: Versionado de directorios CVS solamente sigue la historia de ficheros individuales, pero Subversion implementa un sistema de ficheros de versiones “virtual ” que sigue los cambios por todo el árbol de directorios sobre el tiempo. Ficheros y directorios son versionados. Historial real de versiones Desde que CVS está limitado al versionado de ficheros , operaciones como copiar y renombrar—las cuales pueden ocurrir a ficheros, pero que realmente son cambios al contenido de un directorio —no son soportadas en CVS. Adicionalmente, en CVS usted no puede reemplazar un fichero versionado con cosas nuevas con el mismo nombre sin el nuevo elemento que hereda la historia del viejo —quizás totalmente sin relacionar—fichero. Con Subversion, usted puede añadir, borrar, copiar, y renombrar ficheros y directorios. Y cada fichero nuevo agregado comienza con una nueva, limpia historia enteramente suya. Envíos atómicos Una colección de modificaciones cualquiera entra en el repositorio completamente, o no del todo. Esto permite a los desarrolladores construir y enviar los cambios como trozos lógicos, y previene problemas que pueden ocurrir cuando solo una porción de cambios son enviados al repositorio satisfactoriamente. Metadata versionada Cada fichero y directorio tiene un conjunto de propiedades —claves y sus valores —asociado con él. Usted puede crear y almacenar cualquier par arbitrario de clave/valor que desee. Las propiedades son versionadas a través del tiempo, justo como el contenido de los ficheros. Opciones de las capas de red Subversion tiene una noción abstracta del acceso al repositorio, haciendo fácil para las personas el implementar nuevos mecanismos de red. Subversion puede conectarse al Servidor de HTTP Apache como un modulo de extensión. Esto da a Subversion una gran ventaja en estabilidad e interoperabilidad, y acceso instantáneo a las características existentes que ofrece este servidor—autenticación, autorización, comprensión del hilo , etcétera. También está disponible un proceso más ligero, un servidor de Subversion independiente. Este servidor habla un protocolo propio el cual puede ser fácilmente tunelizado a través de SSH. Manipulación consistente de datos Subversion expresa las diferencias del fichero usando un algoritmo diferenciador de binarios, que funcionan idénticamente con ficheros de texto (legibles por los humanos) y ficheros binarios (no legibles por los humanos). Ambos tipos de ficheros son guardados igualmente comprimidos en el repositorio, y las diferencias son transmitidas en ambas direcciones a través de la red. Ramificación y etiquetado eficientes El coste de ramificación y etiquetado no necesita ser proporcional al tamaño del proyecto. Subversion crea ramas y etiquetas simplemente copiando el proyecto, usando un mecanismo similar al enlace-duro. De este modo estas operaciones toman solamente una pequeña cantidad de tiempo constante. Hackability Subversion no tiene un paquete historico; está implementado como una colección de librerías compartidas de C con una API bien definida. Esto hace de Subversion extremadamente fácil de mantener y reutilizable por otras aplicaciones y lenguajes. 5.3. Instalando Subversion Subversion está construido en una capa de portabilidad llamada APR (la librería Apache Portable Runtime) esto significa que Subversion debería funcionar en cualquier sistema operativo donde corra el servidor httpd Apache: Windows, Linux, todos los sabores de BSD, Mac OS X, Netware y otros. La manera más sencilla de conseguir Subversion es descargando un paquete binario construido para su sistema operativo. La página web de Subversion (http://subversion.tigris.org) tiene a menudo estos paquetes disponibles para la descarga, publicados por voluntarios. El site contiene generalmente paquetes de instaladores gráficos para los usuarios del sistema operativo de Microsoft. Si usted ejecuta un sistema operativo Unix-like, puede usar el sistema nativo de distribución de paquetes de su sistema (RPMs, DEBs, el árbol de ports, etc.) para conseguir Subversion. Alternativamente, usted puede construir Subversion directamente del código fuente. Del website de Subversion, descargue la ultima versión del código fuente. Después de desempaquetarlo, siga las instrucciones del fichero INSTALL para construirlo. Observe que un paquete de código liberado contiene todo lo que usted necesita para construir un cliente de linea de comandos capaz de hablar a un repositorio remoto (en particular, las librerías apr, apr-util y neon). Pero partes opcionales de Subversion tienen muchas otras dependencias, tales como Berkeley DB y posiblemente el httpd de Apache. Si usted quiere hacer una construcción completa , asegúrese que tiene todos los paquetes documentados en el fichero INSTALL. 5.4. Componentes de Subversion Subversion, una vez instalado, tiene un número diferente de piezas. Lo que sigue es una descripción rápida de lo que usted consigue. No se alarme si las breves descripciones le confunden —hay abundancia de páginas en este libro dedicadas a aliviarle esa confusión. svn El programa cliente de linea de comandos. svnversion Programa para reportar el estado (en términos de revisiones de los elementos presentes) de una copia de trabajo. svnlook Una herramienta para inspeccionar un repositorio de Subversion. svnadmin Herramienta para crear, tweaking o reparar un repositorio de Subversion. svndumpfilter Un programa para filtrar mod_dav_svn Un módulo para el Servidor HTTP Apache, usado para hacer disponible su repositorio a otros a través de una red. svnserve Un programa servidor propio independiente, ejecutable como proceso demonio o invocable por SSH; otra manera de hacer que su repositorio esté disponible para otros a través de una red. Suponiendo que ha instalado Subversion correctamente, debería estar preparado para comenzar. Los próximos dos capítulos le guiarán a través del uso de svn , el programa cliente de Subversion de linea de comandos. 6. Implantación Los módulos en donde nos es verdaderamente útil usar el control de versiones son: script de configuración de la base de meta datos, documentos resultado del proceso de investigación, documento final y directorio de trabajo general de los componentes que sea necesario implementar para desarrollo de funcionalidad sea de consultas o de web services. Subversión trabaja con una jerarquía de carpetas similar a un explorador de archivos por lo que es posible definir carpetas que contienen los documentos compartidos. Por esta razón decidimos definir las carpetas de trabajo de la siguiente forma: Biblioteca2: Contiene el paquete de trabajo del proyecto definido de la misma forma en que fue previamente desarrollado, con cada uno de los archivos fuente, agregamos una carpeta que contiene el script de configuración de la base de meta datos. Igualmente se conserva la idea de mantener en paquetes separados el desarrollo WEB del desarrollo en la capa de negocio. Por el lado de presentación conservamos las jsp, los documentos de estilos, la plantilla principal y las imágenes, mientras por el lado de la capa de negocio conservamos los archivos fuente, los bytecodes generados y los properties. Artefactos: Esta carpeta estará dividida por etapas concretas del proyecto. Las carpetas son, Adaptación: corresponde a los documentos de configuración generados mientras se comprendía el proyecto y se subía, Versionamiento: que contiene el documento de definición de versiones y el manual de uso del svn y de consulta del repositorio creado para el proyecto en particular, WebServices: al cual se le ingresa el documento de configuración de webservices en donde se encuentra además la descripción del cliente swing generado para efectuar las pruebas, Consultas:en donde estará el documento aprobado de consultas y los documentos que se puedan generar posteriormente y finalmente Pruebas: en donde se mantendrá el resultado de las pruebas que se generen. Diseño: Acá guardaremos los documentos de diseño que nos dejaron previamente nuestros compañeros y que serán modificados a medida que se apliquen cambios sustanciales al proyecto. Documento Final: Al cual le hemos dedicado un espacio exclusivo para tener claros los cambios que sufra una vez se le apliquen las correcciones necesarias.