RWJ. Control de versiones: Subversion (y II)

Como comentábamos en el post anterior,  cuando hacemos un commit de un directorio del proyecto (el raíz tambien es un directorio)  SVN va a comprobar que, para cada fichero marcado como modificado, la versión base del fichero en nuestra working copy  coincide con la última versión de ese fichero subido al repositorio. En caso de no coincidencia sería necesario actualizar primero los contenidos de la working copy con la última versión que hay en el repositorio.


Los directorios también mantienen un número de versión que cambia cuando cambia el número de versión de alguno de sus contenidos. Además es posible guardar un comentario con cada commit


¿Y esto llega para todo lo que hablamos? ¿Marcar versiones entregadas del código fuente del proyecto? ¿Mantener ramas de desarrollo paralelas? ¿Sólo con esto?


Pues para conseguir esto hay que basarlo en convenciones. Cuando se crea un repositorio y antes de empezar a subir ficheros hay que crear tres directorios :

• branches
• tags
• trunk

Una vez creados estos directorios en el repositorio ( que, por ejemplo, tendrá la url http://repo/svn/miproyecto/ ) cada integrante del equipo de desarrollo tendrá que hacer un checkout sobre http://repo/svn/miproyecto/trunk . Este directorio albergará la rama principal de desarrollo y todo el equipo trabajará contra él.


Independientemente de que las versiones de svn se numeren secuencialmente es recomendable nombrar cualquier software con un formato  x.y.z   . Cambios pequeños en el software - por ejemplo, corrección de bugs- deberían incrementar el número z . Cambios funcionales notorios deberían incrementar el número y, mientras que el valor de x aumentaría sólo con cambios profundos en el producto.


Cuando el código de trunk cumple con los objetivos que el equipo de desarrollo ha marcado para liberar una versión del programa se lanza sobre el repositorio un copy to de la rama /trunk en un directorio con la versión de software, por ejemplo, /tags/1.0.0 . En las observaciones de esta operación es recomendable indicar el changelog del software. 


De esta manera, el directorio /tags/1.0.0 pasaría a contener la versión 1.0.0 del software , mientras que el equipo de desarrollo seguiría desarrollando con su working copy apuntando a /trunk . Sucesivas versiones del software se marcarían de esta misma forma. 


En proyectos más complejos en los que es necesario dar soporte a diferentes versiones del producto puede surgir la necesidad de abrir una rama de desarrollo paralela al trunk  - cuya última versión liberada fue la 3.5.1 -  por ejemplo, para corregir bugs sobre una versión 2.2.0 . En este caso el procedimiento a seguir sería hacer un copy to de /tags/2.2.0 a /branches/2.2.x  , comentando la apertura de una rama paralela de desarrollo. El equipo responsable de la rama debería hacer un nuevo checkout del proyecto sobre la URL http://repo/svn/miproyecto/branches/2.2.x . Nuevas versiones del programa desarrollado sobre el trunk se seguirán etiquetando como hasta ahora mientras que las nuevas releases del branch se etiquetarán manteniendo las versiones de la rama. En nuestro caso el número de la siguiente versión sería 2.2.1 


Por último, puede que modificaciones de algunos ficheros en la rama deban pasar al trunk - es el sentido habitual de incorporación-. En estas circunstancias es cuando procede hacer un merge de ambas ramas. Esta parte es un poco más compleja y la maestría haciendo merges sólo se consigue haciendo muchos.


Si no estáis usando un sistema de control de versiones, ¿a qué esperáis?