Documento de Configuración del Control de Versiones para trabajo

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.