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