Universidad del Valle Taller de CVS

Universidad del Valle
Taller de CVS - Control de Versiones
Desarrollo de Software II
Profesora: María Eugenia Valencia
En el siguiente taller se hará un seguimiento de los comandos -con su
respectiva descripción- que se pueden utilizar con cvs, para ello se han
especificado ejemplos que servirán de guía a los estudiantes.
1. Creación de un grupo de trabajo
En primer lugar, es necesario crear un grupo de trabajo que relacione un grupo
de usuarios entre si para poder asignarles los permisos necesarios.
1.1 Creación del grupo:
pts creategroup <userName>:<groupName>
Ej:
pts creategroup dipatasu:desarrollo2
El “userName” con el cual se crea un grupo de trabajo debe ser el
login del propietario de la cuenta en la cual se esté trabajando.
NOTA:
Si desea eliminar un grupo completamente:
pts delete <groupName>
Ej:
pts delete dipatasu:desarrollo2
1.1.1 Agregando usuarios al grupo:
pts adduser -user <userName>+ -group <groupName>
Ej:
pts adduser -user maletruv jeanmecl jofelipe -group
dipatasu:desarrollo2
NOTA:
Si desea eliminar un usuario de un grupo:
pts removeuser -user <userName> -group <groupName>
Ej:
pts removeuser -user maletruv -group dipatasu:desarrollo2
1.1.2 Revisar cambios
Para ver el grupo creado:
pts listowned -name <user>
Ej:
pts listowned -name dipatasu
Para listar los usuarios del grupo:
pts membership -name <userName>
Ej:
pts membership -name dipatasu:desarrollo2
1.2 Asignación de permisos de acceso:
Es necesario asignar permisos de lectura al directorio raíz y luego,
permisos para ejecutar comandos cvs en el directorio en el que se
vaya a trabajar
cd
fs setacl -dir <directory>+ -acl <accesslist entries>+
Ej:
fs setacl -dir . -acl dipatasu:desrrollo2 l
Así el grupo sólo tiene permisos de lookup(l) al home del usuario
propietario. Para ver los usuarios o grupos que tienen acceso al
directorio home y los permisos de éstos ejecute:
fs listacl [path]
Ej:
fs listacl .
Ahora se deben asignar los permisos de ejecución en el directorio
en el que se almacenará el repositorio. Si no existe el repositorio,
se debe crear:
mkdir nombreRepositorio
cd ~/nombreRepositorio
fs setacl -dir . -acl <groupName>
Ej:
mkdir miRepos
cd ~/miRepos
fs setacl -dir . -acl dipatasu:desarrollo2
2. Creación de un repositorio
Para comenzar a trabajar, es necesario definir un lugar donde se almacenarán
todos los archivos... El repositorio es ese lugar , y se creará en la cuenta del
propietario del grupo de trabajo.
cvs -d <path-to-repos>init
Ej:
cvs -d ~/miRepos init
3. Trabajando con el repositorio
3.1 Importar proyecto
Al comenzar a trabajar con el repositorio seguramente ya existirá un
directorio donde se encuentren los archivos que se desean
administrar con cvs. Siendo así es necesario decirle al repositorio
cuáles son estos archivos.
cd ~/directorioDondeSeEncuentranLosArchivos
cvs -d <ruta-absoluta-Repos> import -m “<mensaje>” <nameproy> <vendorTag> <releaseTag>
vendorTag no es actualmente usado por cvs y puede contener
cualquier información que quieras poner.
 releaseTag puede ser usado para especificar releases (versiones)
específicas.
Estas etiquetes TIENEN que ser incluídas en el comando import.

Supongamos que los archivos se encuentran en el directorio
~/miProyecto
Ej:
cd ~/miProyecto
cvs -d ~/miRepos import -m “versión inicial”
dipatasu inicial
proyDesarrollo
3.2 Copias de trabajo
Ahora que el proyecto existe en el repositorio, el directorio de
origen podría ser eliminado completamente sin crear ningún tipo de
conflicto. Pero lo fundamental es poder extraer el repositorio las
copias del proyecto
3.2.1 Propietario
Para extraer una copia de trabajo dentro de la cuenta del
propietario se usa la siguiente instrucción:
cvs -d <path-to-repos> checkout <name-proy>
Ej:
cvs -d ~/miRepos checkout proyDesarrollo
Esta instrucción crea un directorio con el nombre del
proyecto en donde se ubica la copia de trabajo, y otro de
control de CVS que NO debería ser manipulado por el
usuario
3.2.2 Otros usuarios
cvs -d :ext:<host>:<path-to-Repos> checkout <name-Proy>
Ej:
cvs -d :ext:s3pc:/afs/users/pregrado/2001/dipatasu/miRepos
3.3 Actualizar proyecto
Luego de haber realizado cambios a un archivo del proyecto,
seguramente se deseará actualizar la línea base del proyecto para
que todos los usuarios accedan de ahora en adelante a la última
versión.
3.3.1 Update
cvs update -dP actualiza la información de la copia local de
acuerdo a lo existente en el repositorio, realizando los
cambios pertinentes de modo LOCAL. Según los cambios
realizados se informará con una letra descriptiva sobre cada
fichero la acción realizada.
"-d" le dice al comando cvs que cree cualquier directorio que
haya sido agregado al repositorio (esto no es la opción por
defecto), y "-P" le dice al cvs que remueva/borre cualquier
directorio vacío de tu copia local de las fuentes. "-P" es una
buena idea, ya que cvs tiene la tendencia de recolectar un
montón de directorios vacíos a través del tiempo. (que
alguna vez fueron usados, pero han sido abandonados).
3.3.2 Commit
Luego de actualizar los cambios a modo local es posible
validar los cambios para que se registren en el repositorio.
cvs commit -m “comentario descriptivo” actualiza el repositorio
con los cambios locales y crea una nueva versión del
proyecto.
Ej:
cvs commit -m “se han hecho unas cuantas modificaciones”
3.4 Añadir ficheros
Si se desea añadir nuevos ficheros que no existían en el
repositorio, se le debe indicar a cvs cuáles son estos ficheros, y
luego con commit validar la inclusión.
Ej:
cvs add <ficheroNuevo>
cvs commit -m “hay un nuevo fichero: ficheroNuevo”
NOTA: cabe anotar que para adicionar el nuevo fichero, éste se
debe encontrar en la copia local del repositorio.
3.5 Mezclas
Muchas veces, cuando hay varios usuarios trabajando sobre un
mismo archivo puede ocurrir que los archivos del repositorio
cambien y al realizar un update se produzcan conflictos. CVS lo
notificará con un mensaje así:
cvs update: Updating .
RCS file: ~/miRepos/proyDesarrollo/fich,v
retrieving revision 1.5
retrieving revision 1.6
Merging differences between 1.5 and 1.6 into fich
rcsmerge: warning: conflicts during merge
cvs update: conflicts found in fich
C fich
3.5.1 Resolviendo conflictos
En este caso el usuario deberá decidir qué cambios dejar en
el archivo resultante. Los conflictos serán indicados por cvs
con bloques indicadores “<<<” y “>>>”.
Ej:
<<<<<<< fich
día 14 Sep 2006
Aquí hay algo que yo he añadido.
=======
día 14 Sep 2006
Aquí hay algo que añadió otro desarrollador
>>>>>>>
El usuario debe reemplazar la región en
(manualmente) y borrar los marcadores “===”.
conflicto
3.6 Borrar
Para eliminar ficheros del repositorio de forma permanente es
necesario primero borrarlos de la copia local y luego notificarle a
CVS que el fichero será eliminado, finalmente el comando commit
validará los cambios ante el repositorio.
Ej:
rm Archivo.txt
cvs remove Archivo.txt
cvs commit -m “Se ha eliminado el Archivo.txt”
4. Control de ramas y versiones
Cuando se trabaja con múltiples versiones, muchas veces se requiere acceder
a una versión antigua para hacer cambios nuevos a partir de ésta, (por
ejemplo: la última versión es defectuosa). Además, suele ocurrir que el trabajo
se ve ramificado en múltiples ramas, debido a los múltiples desarrolladores,
CVS provee control sobre este tipo de situaciones facilitando así el
mantenimiento de la línea base.
4.1 Versiones
Cuando se requiere acceder a una versión antigua, lo primero es
saber a cuál de todas las versiones antiguas se desea acceder. CVS
provee varios métodos; uno es etiquetar las versiones con nombres
fáciles de recordar, el otro es acceder a través del número de la
versión, para ello es necesario conocer las versiones, y esto puede
hacerse gracias a los comentarios que se asocian a cada versión
luego de un update.
4.1.1 Historial de un archivo
cvs log <nombreFichero> provee información sobre las
revisiones y versiones de los ficheros, listando también los
comentarios hechos por el usuario al hacer commit a sus
cambios. De este modo podrán identificarse las versiones, (si
los comentarios son descriptivos), y así acceder a las
versiones deseadas.
Suponiendo que la versión actual es 1.5 y se desea acceder a la
versión 1.3:
cvs checkout -r 1.3 proyDesarrollo
4.2 Ramas
4.2.1 Creación
Cuando se desea trabajar con ramas sobre la línea base se
especifica con la siguiente instrucción:
cvs tag -b <etiqueta-Rama>
Ej:
cvs tag -b miRama
4.2.2 Acceso
Al crear la rama, se supone que se trabajará sobre ella. Es
necesario indicarle a CVS que se trabajará sobre dicha rama
en la copia de trabajo. Hay dos formas de hacerlo:
4.2.2.1 Cuando se hace el checkout
cvs checkout -r rel-1-0-patches tc
4.2.2.2 Cuando ya se ha hecho el checkout y se
desea actualizar la copia de trabajo:
cvs update -r rel-1-0-patches tc
4.2.3 Mezcla
Cuando luego de trabajar sobre una rama y sobre la línea
base de forma concurrente llega el punto en el que se
desea unificar los cambios hechos, se procede a hacer
merging sobre las ramas.
Para mezclar una rama con otra, primero se debe estar en
la rama de destino, o la rama que consolidará los cambios.
Luego se utiliza un comando para obtener los cambios
desde otra rama.
Primero se obtiene la versión sobre la cual se quieren
actualizar los cambios y luego se hace un “join” de la rama
y la versión. Finalmente, se notifica a cvs de los cambios
con commit:
cvs -d ~/miRepos checkout proyDesarrollo
cvs update -j miRama archivo.java
.
.
cvs commit -m "Se incluyó la rama miRama a la línea
base"
Si se continúa trabajando con la rama después de haber
hecho la mezcla, y se desea nuevamente actualizar la
mezcla es necesario conocer el número de la última versión
de la rama:
E
n
e
l
diagrama se ha actualizado la versión 1.5 con los cambios
en la rama Rifix 1.2.2.2, pero luego se produjo la versión
1.2.2.3
Para actualizar la línea base con la versión 1.2.2.3 de Rifix
se indica:
cvs update -j 1.2.2.2 -j R1fix archivo.java
Enlaces de interés
http://www.gentoo.org/doc/es/cvs-tutorial.xml
http://docs.moodle.org/es/CVS_para_desarrolladores
http://www.tuxpan.com/fcatrin/files/cvs.html