Proyecto ROOTVE V2: Control de versiones con Subversion Grupo de Investigación y Desarrollo en Seguridad de la Información - GIDSI

Agenda Seguimiento proyecto ROOTVE V2 Subversion –Organización del repositorio –Ramas (branches) y Etiquetas (tags) –Buenas prácticas en Subversion –¿Cúando crear ramas? –Estrategias para definición de ramas Discusión y selección de estrategias para ramas del proyecto

Seguimiento proyecto ROOTVE V2 Uso del sistema TRAC

Subversion Sistema centralizado para compartir información El núcleo es un repositorio; control de versiones Almacenamiento de información bajo un árbol de sistema de archivos Conexiones de clientes al repositorio

Subversion: URLs

Subversion: un repositorio

Subversion: copia de trabajo Arbol de directorio local Espacio de trabajo privado del usuario Comandos disponibles para publicar cambios y obtener cambios –checkout, commit, update

Subversion: revisiones Publicación de cambios a archivos o directorios en una sola transacción Generadas por un commit Refleja un nuevo estado del árbol del sistema de archivos Tienen asociadas un número: –Revisión N -> estado del repositorio después del commit N

Subversion: revisiones

Organización del repositorio

Ramas (branches) Básicamente una línea de desarrollo que existe independientemente de otra línea Historia común

Ramas (branches) La creación de una rama no es más que la copia del proyecto en el repositorio: –svn copy Sobre una rama se pueden ejecutar las mismas operaciones que sobre el trunk

Ramas (branches)

Ramas (branches)

Ramas (branches) Subversion no conoce las nociones de ramas ni tags: –Sólo conoce de copias de directorios Las ramas son nociones que los humanos damos a las copias de directorios Las ramas existen como directorios en el árbol del sistema de archivos del repositorio Por convensión se colocan en /branches Las ramas son susceptibles de actualizarse

Merging es el acto de reconciliar múltiples cambios hechos a copias diferentes de un mismo archivo Los cambios de una rama se pueden replicar en el /trunk con: –svn merge Merging (~ fusionar/fundir)

Una etiqueta corresponde a una instantánea del proyecto en el tiempo Se asignan nombres “amigables” para los usuarios: –p.ej: rootve Generalmente utilizadas para release de versiones de software Se ubican en /tags dentro del repositorio Etiquetas (tags)

Utilizar una organización del repositorio con una raíz de proyecto: –/trunk, /branches y /tags “Commit” cambios lógicos: –reflejar un propósito específico Establecer enlaces entre los cambios de subversion y el sistema de tickets Utilizar los mensajes de log para commit y merge Buenas prácticas en Subversión

Depende de la naturaleza del proyecto de software Se proponen momentos de acuerdo al sistema: ¿Cuándo crear ramas? 1.- The Never-Branch system –Los usuarios hacen commit del trabajo dirario sobre /trunk. –Ocasionalmente el /trunk no compila o genera errores con cambios complicados

¿Cuándo crear ramas? 2.- The Always-Branch system –Cada usuario trabaja sobre una rama privada para cada tarea de codificación –Cuando el código se completa, “alguien” revisa los cambios de la rama y los fusiona (merges) en el /trunk Aquí se garantiza que el /trunk sea estable la mayor parte del tiempo, pero pueden ocurrir conflictos al fusionar

¿Cuándo crear ramas? 3.- The Branch-When-Needed system –Los usuarios hacen commit el trabajo diario sobre /trunk –Regla1: /trunk debe compilar y pasar pruebas –Regla2: Un commit no debe ser muy “largo”; debería ser concreto –Si hay un conflicto con regla1 y regla2 el usuario debería crear una nueva rama y hacer commit de los cambios allí Aquí se garantiza que el /trunk sea estable la mayor parte del tiempo y los conflictos de fusionar son raros

¿Cuándo crear ramas? Se pueden considerar ramas desde el punto de vista de: –Release: basadas en release –Feature: basadas en características o funcionalidades

¿Cuándo crear ramas? Release: –Desarrolladores colocan trabajo diario, nuevas características, corrección de errores en /trunk –Cuando se decide que el software está listo para release se copia /trunk a /branches/1.0 –Trabajo en paralelo. Los errores aparecidos en cualquier rama se corrigen y se portan a las otras (merge) –Se congela la rama y se libera como un tag: /tags/1.0.0 –La rama /branches/1.0 se mantiene a lo largo del tiempo. El trabajo en /trunk continua, correcciones de errores son portadas a /branches/1.0 para luego liberar /tags/1.0.1

¿Cuándo crear ramas? Feature: –Rama temporal creada sólo para trabajar en cambios complejos sin interferir con la estabilidad del /trunk –Se crean, se utilizan por un tiempo, se fusionan de regreso con el tronco y finalmente son borradas –Desventaja: el código del tronco es, con frecuencia, inestable

Estrategias para definición de ramas Tronco Inestable

Estrategias para definición de ramas Tronco Estable

Recomendaciones Si se decide usar ramas, hay que cuidarlas y mantenerlas Al momento de hacer un release crear una rama Si no se va a realizar una fusión desde o hacia una rama, no crear una rama sino un tag Evitar la creación de ramas para cambios simples Ejemplo práctico: mantenimiento y desarrollo-> mantener versión N mientras se desarrolla versión N+1

Discusión y selección de estrategias para ramas del proyecto En consenso debemos establecer: –Tiempo entre liberaciones –Tipo de estrategia de ramas a utilizar –Nombre de las ramas a generar –Tiempo entre actualizaciones de ramas al tronco –Tiempo entre actualizaciones de tronco a ramas –Entre otras políticas que consideremos...

v svn://seguridad.cenditel.gob.ve/var/local/svn/seguridad/rootvev2/ URL Subversion ROOTVE V2