A continuacion realizo un resumen de la informacion que alli encontre, junto con algunas notas propias.
Introduccion
Generalmente cuando uno habla de la estructura de un repositorio con algun sistema de control de versiones (subversion, cvs, etc.) se queda en la estructura basica:
/
- Trunk
- Branch
- Tag
Encontrando en "trunk" la ultima version del codigo fuente, en "branch" las ramas que se utilizan para agregar ciertas funcionalidades al sistema sin que esto interfiera con el desarrollo principal del sistema (trunk), y por ultimo "tag" para identificar ciertos puntos que queremos mantener (ejemplo la salida de una version).
Hasta ahora no habia encontrado demasiado informacion de como hacer una organizacion un poco mas detallada de cada una de las "ramas" (trunk, branch, tag). Pero luego de leer la serie de articulos de la pagina que mencione anteriormente, he encontrado una estructura un poco mas detallada y que me parece mucho mas logica para los sistemas.
Mi experiencia
En los sistemas que he venido desarrollando he utilizado la estructura basica y me ha venido muy bien. Teniendo en trunk siempre la ultima version del sistema, y en generando una copia especifica en "tag" de cada version que sale del sistema. No he utilizado demasiado "branch" ya que la mayoria de los cambios eran realizados sobre el flujo principal (trunk). En las ocasiones que tenia que realizar pruebas demasiado experimentales (que no sabia si podian funcionar), si he realizado un "branch" del codigo principal que se encuentra en trunk como para poder trabajar un poco mas tranquilo.
Hoy en dia estoy trabajando sobre proyectos mas complejos, los cuales necesitan de una estructura un poco mas detallada, y antes de intentar generar mi propio standard, decidi buscar un poco mas para ver como otras personas organizaban sus repositorios.
Debo reconocer que aun estoy con la estructura tradicional de repositorios y que por el momento no he decidido como migrar esa estructura a una que me pueda ser mucho mas practica.
La propuesta
Luego de leer http://ariejan.net pude encontrar otras formas de encarar lo mismo y me dio la posibilidad de "entender" un poco mas a fondo como puede ayudar la estructura en varios aspectos mas (que sea mas facil su integracion con los sistemas de gestion de errores/bugs).
Voy a intentar explicar un poco el metodo de trabajo que es la forma en la cual se explaya este articulo.
1. Una vez creado el repositorio, debemos seguir trabajando normalmente sobre la version que se encuentra en trunk.
2. Cuando vamos a lanzar una version, generamos un branch para dicha version (no la trabajamos como un tag del trunk, sino como un tag de un branch). Es decir, generamos una copia del trunk en un branch, y luego trabajamos todo lo que sea necesario sobre dicha copia hasta que el sistema este listo para ser lanzado (no deberia ser demasiado trabajo, ya que el trunk deberia estar maduro como para intentar lanzar una version). Una vez que la version que estamos trabajando en el branch esta lista, realizamos un tag de dicha version.
3. Cuando un error sencillo de corregir es detectado, el mismo es solucionado sobre el branch, y luego se soluciona sobre el trunk (que seguramente debe tener dicho error).
4. Cuando un error dificil de corregir es detectado, se realiza un tag PRE-
Tiene una nomenclatura muy sencilla para los branch y tags que se utilizan en el repositorio:
- En branches
- RB-
: para identificar un Release Branch. Cuando se desea hacer una version del sistema a partir del trunk. Se genera una release branch, la cual tiene la copia del trunk, y el numero de version con la cual saldra. - BUG-
: para identificar las branches que se utilizan para corregir errores que son complejos (implican un cambio importante en el codigo fuente del sistema) - TRY-
: son branch destinados a realizar pruebas sobre el codigo principal, que no se esta seguro que las mismas funcionen. Se puede utilizar para actualizacion de versiones de componentes - En tags
- REL-
: para identificar "releases" (deliverables) del sistema. - PRE-
: para identificar como estaba el codigo antes de corregir un bug que es complejo (utilizado junto con el branches BUG- ) - POST-
: para identificar el codigo luego de corregir un bug que es complejo (utilizado junto con tags PRE- y branches BUG-
Conclusion
Si bien es bastante logico como trabaja las versiones, no habia encontrado tanto detalle en otros sitios y documentaciones que habia leido. Me parecio interesante el ver como detalla cada "paso" en la salida del codigo y la utilizacion de nomenclatura que hace mucho mas sencillo conocer que se ha realizado.
Quizas para algunas personas esto no aporte nada, hasta quizas lo manejaba de esa forma, o esta contento como lo viene trabajando y es de una manera totalmente distinta. Todo es valido en esto, nadie tiene la verdad absoluta sobre las cosas, pero siempre es interesante el poder conocer como otras personas con mas experiencia en el manejo de repositorios, solucionan ciertos inconvenientes o hacen la vida mas sencilla.
Antes de este articulo, yo realizaba los tags sobre el trunk del repositorio, es decir, no generaba un branch con el release, lo trabajaba y luego generaba el tag sobre le mismo. No me ha traido inconvenientes trabajarlo como lo venia haciendo, pero si se me hacia un poco mas complejo al momento de solucionar bugs, ya que estaba forzado a trabajar siempre sobre la ultima version del repositorio.
