PDF de programación - Uso practico de CVS para control de versiones - Conceptos y practicas recomendadas

Uso practico de CVS para control de versiones

Conceptos y practicas recomendadas

Franco M. Catrin L.

Uso practico de CVS para control de versiones: Conceptos y practicas recomendadas
por Franco M. Catrin L.

Copyright © 2003 4to Encuentro Nacional de Linux

Historial de revisiones
Revisión 1.0 25-02-2003 Revisado por: FCL
Primera version

Tabla de contenidos

1. Resumen .............................................................................................................................1
2. Introduccion.......................................................................................................................3
Arquitectura de CVS....................................................................................................3
Forma de trabajo basica...............................................................................................3
Limites de CVS como herramienta............................................................................3
3. Uso basico de CVS............................................................................................................5
Repositorio ....................................................................................................................5
Modulo...........................................................................................................................5
Trabajo basico con CVS : update y commit ..............................................................6
Agregando y eliminando archivos ............................................................................7
Obtencion de diferencias entre repositorio y version local....................................8
4. Caracteristicas avanzadas de CVS .................................................................................9
Uso de TAG’s ................................................................................................................9
Uso de ramas (branches) .............................................................................................9
Mezcla de ramas (merge).................................................................................10
5. Practicas recomendadas .................................................................................................11
Uso de ramas estables e inestables ..........................................................................11
Uso de ramas experimentales...................................................................................11
Numero de versiones.................................................................................................12
6. Conclusiones....................................................................................................................13

iii

iv

Capítulo 1. Resumen

El control de cambios es necesario para el desarrollo de cualquier tipo de proyectos
de software. La herramienta mas utilizada para esta labor en proyectos Open Source
es CVS (Concurrent Version System). Este documento presenta los conceptos basicos
de CVS, asi como tambien caracteristicas avanzadas y practicas recomendadas para
su efectiva utilizacion.

1

Capítulo 1. Resumen

2

Capítulo 2. Introduccion

El desarrollo de software no es una tarea exclusivamente individual. En la gran
mayoria de los proyectos tanto Open Source como privados es necesario trabajar
en equipos en donde son varios los desarrolladores que acceden al mismo codigo
fuente.
Coordinar las modificaciones concurrentes al codigo de una forma manual es una
tarea titanica, sobre todo en proyectos muy complejos o con una gran cantidad de
desarrolladores.
Uno de los objetivos de CVS es proveer una herramienta que permita mezclar distin-
tos cambios al codigo para consolidar un codigo unico final de una forma automati-
zada, siempre que sea posible.
Otro de las funciones que cumple una herramienta como CVS es mantener un registro
de los cambios que se hacen al codigo fuente. De tal forma que se tenga acceso a todo
el historial de cambios del proyecto. Esta caracteristica permite volver a versiones
anteriores, encontrar defectos introducidos y mantener un mismo proyecto en una
version "estable" y "en desarrollo" a partir de un solo repositorio comun.
Estas capacidades son de vital importancia en proyectos Open Source, en donde los
desarrolladores estan separados geograficamente y temporalmente. Sin embargo las
mismas practicas son tambien aplicables a proyectos privados.

Arquitectura de CVS

CVS es una herramienta que funciona en un esquema de cliente y servidor. Existe
un cliente o estacion de trabajo en donde los desarrolladores hacen modificaciones
al codigo y realizan las pruebas necesarias para satisfacer los requerimientos. En el
servidor existe una version consolidada del proyecto. Cada cierto tiempo los desar-
rolladores actualizan sus versiones de trabajo desde el servidor y por otra parte en-
vian sus propios cambios hacia el servidor.
Existen servidores para Linux y Unix, asi como clientes para una extensa gama de
plataformas (Linux, Windows, MacOSX, etc).
Uno de los beneficios de este esquema, es que se puede integrar la funcionalidad
de cliente CVS en las herramientas de desarrollo integradas (IDE). En la plataforma
Linux es comun que se realice esta integracion, debido a lo fundamental que se ha
convertido CVS en la mayoria de los proyectos que integran esta plataforma, in-
cluyendo los mismos proyectos de desarrollo de estos IDE’s. Es asi como por ejemplo
podemos encontrar KDevelop de KDE, Anjuta y Eclipse en GNOME integrados (y
desarrollados) con CVS

Forma de trabajo basica

Cada archivo que compone el proyecto puede ser modificado por varios desarrol-
ladores al mismo tiempo en forma independiente. CVS se encarga de consolidar los
distintos cambios en un solo archivo final que incluya todos los cambios introducidos
por los distintos desarrolladores.
Existe solo un caso especial en donde mas de un desarrollador puede introducir cam-
bios en la misma parte del codigo. Esto se conoce como conflicto. Es tarea del usuario
que produce el conflicto, resolverlo y enviar una version consolidada al servidor
Cada archivo tiene un numero de revision independiente. Este numero registra el
numero de cambios hechos al archivo y no tiene ninguna relacion con algun numero
de version del proyecto completo. Mas adelante se vera como se pueden manejar los
archivos almacenados en CVS como un conjunto

3

Capítulo 2. Introduccion

Limites de CVS como herramienta

CVS como herramienta no resuelve todos los problemas del desarrollo en equipo.
Simplemente es una ayuda para que las cosas mas tediosas puedan ser automati-
zadas.
Las areas en donde CVS no esta involucrado tienen relacion con el tratamiento
del proyecto a un nivel global. Actividades como la planificacion, los releases, etc,
quedan fuera de su ambito de trabajo y deben ser abordadas por las personas y
otras herramietnas complementarias

4

Capítulo 3. Uso basico de CVS

CVS es una herramienta bastante flexible, no es necesario utilizar todas las caracter-
isitcas que posee, pero si al menos se debe tener conocimiento de las operaciones
mas elementales para comprender las funcionalidades mas avanzadas y que son de
interes en este trabajo.

Repositorio

En la parte de servidor de CVS se maneja un repositorio. Un repositorio es simple-
mente un directorio en el servidor que contiene diversos modulos. Por ejemplo, un
proyecto podria tener un repositorio, y en cada modulo estarian los subproyectos.
A su vez, cada modulo contiene un conjunto de archivos, y representa al proyecto
con el que se quiere trabajar. Por ejemplo en sitios grandes como sourceforge, cada
uno de los proyectos tiene su propio repostorio CVS, y cada uno de ellos tiene uno o
mas modulos de trabajo. Cuando un desarrollador trabaja con CVS lo hace a nivel de
modulo.
Para conectarse al servidor se pueden usar distintos tipos de protocolos, sin embargo
los mas extendidos son "pserver" para acceso anonimo o algun tipo de acceso en
donde la seguridad no es importante. El otro es ssh, y se usa en casos mas criticos,
por ejemplo cuando se requiere acceso para poder realizar cambios al repositorio.
Para que un directorio pueda ser utilizado como repositorio CVS, lo primero que se
debe hacer es decirle a CVS que genere los archivos y subdirectorios necesarios para
funcione como tal. Podriamos crear un repositorio con los siguientes comandos:
Primero creamos un grupo especial para que pueda hacer cambios en CVS

[root@shaman root]# groupadd cvs

Luego se crea un directorio para almacenar el repositorio

[root@shaman root]# cd /usr/local/
[root@shaman local]# mkdir cvs-utfsm

Se indica a CVS que inicialice el directorio recien creado

[root@shaman local]# cvs -d /usr/local/cvs-utfsm init

Se actualizan los permisos para que los usuarios del grupo CVS efectivamente tengan
control sobre el repositorio

[root@shaman local]# chown root.cvs -R cvs-utfsm
[root@shaman local]# chmod 775 cvs-utfsm

Como resultado se obtendra un directorio CVSROOT al interior de cvs-utfsm. Este
directorio contiene los archivos necesarios para que CVS lo trate como un repositorio

Modulo

Un modulo contiene un grupo de archivos que se administra de manera conjunta. Por
ejemplo, cada vez que se realiza alguna actualizacion a nivel de conjunto de archivos,
el ambito sera de un modulo.
Cada repositorio puede tener un numero indefinido de modulos, Se sugiere siempre
tener los archivos relacionados con un modulo de software bajo un unico directorio.
5

Capítulo 3. Uso basico de CVS

De esta forma, habra una correspondencia univoca entre el modulo de software y un
modulo CVS.
Para comenzar a trabajar en un modulo a partir del repositorio de ejemplo que se ha
creado, lo primero que debemos hacer es importarlo. En este ejemplo se usará una
conexion SSH hacia el servidor (aunque sea local).
El primer paso es definir una variable de entorno que para indicar que el protocolo a
usar es SSH.

export CVS_RSH=ssh

Luego se define una variab