¿Cuál es un buen layout de repository para lanzamientos y proyectos en Subversion?

Tenemos el layout estándar de tronco / twigs / tags de Subversion. Tenemos varias sucursales para proyectos a mediano y largo ploop, pero ninguna hasta ahora para un lanzamiento. Esto se acerca rápido.

Deberíamos:

  1. Mezcle twigs de lanzamiento y twigs de proyecto juntas?
  2. Crear una carpeta de lanzamientos? Si es así, ¿hay un nombre mejor que las versiones?
  3. Crear una carpeta de proyectos y mover las twigs actuales allí? Si es así, ¿hay un nombre mejor que los proyectos? He visto "sandbox" y "spike" en otros repositorys.
  4. ¿Algo más en total?

Recomiendo el siguiente layout, por dos razones: – todo lo relacionado con un proyecto dado se encuentra dentro de la misma parte del tree; hace que sea más fácil de entender para las personas – el event handling permissions puede ser más fácil de esta manera

Y dicho sea de paso: es una buena idea con pocos repositorys, en lugar de muchos, porque el historial de cambios normalmente se conserva mejor de esa manera (el historial de cambios se pierde si mueve los files entre repositorys, a less que realice una acción especial y algo complicada). En la mayoría de las configuraciones, solo debe haber dos repositorys: el repository principal y un repository de espacio aislado para las personas que experimentan con Subversion.

project1 trunk branches 1.0 1.1 joes-experimental-feature-branch tags 1.0.0 1.0.1 1.0.2 project2 trunk branches 1.0 1.1 tags 1.0.0 1.0.1 1.0.2 

Partiendo de lo que otros han dicho, tenemos una estructura bastante rígida de progresión de alfa, a beta, a producción. El código alfa es lo que sea la cabeza del tronco, y se mantiene estable en su mayor parte, pero no siempre. Cuando estamos listos para lanzar, creamos una "twig de publicación" que efectivamente congela ese código, y solo se le aplican correcciones de errores. (Estos se transportan de vuelta al maletero). Además, las tags se crean periódicamente como candidatos de lanzamiento, y estas son las versiones beta. Una vez que el código pasa a producción, la twig de publicación se mantiene abierta para soporte, security y corrección de errores, y las versiones menores son labeldas y liberadas de esto.

Una vez que una versión particular ya no es compatible, cerramos la twig. Esto nos permite tener una clara distinción de qué errores se arreglaron para qué lanzamientos, y luego se mueven al tronco.

Los cambios importantes, a largo ploop o masivos que romperán el sistema por largos períodos de time también reciben su propia twig, pero estos tienen una vida más corta, y no tienen la palabra "liberación" en ellos.

Cuando queremos prepararnos para el lanzamiento de, digamos, la versión 3.1, creamos una twig de branches / 3.1-Release y fusionamos commits individuales desde el trunk como nos parezca oportuno (nuestras twigs de lanzamiento usualmente solo reciben las correcciones más importantes de las principales twig de desarrollo).

Por lo general, esta twig de versión vive a través de las fases de testing alfa y beta, y se cierra cuando la siguiente versión se encuentra en el umbral.

Lo que también puede hacer, una vez que se presionan sus DVD o se carga su package de descarga, es labelr la twig de publicación como liberada, por lo que puede rebuild fácilmente desde exactamente la misma revisión si lo necesita más adelante.

Carl

Ya usamos tags, aunque tenemos la estructura de un proyecto grande en lugar de los muchos proyectos pequeños que ha descrito.

En este caso, necesitamos labelr, por ejemplo, 1.0.0, pero también bifurcar, por ejemplo, 1.0. Mi preocupación es mezclar twigs de proyectos y twigs de liberación, por ejemplo

 branches this-project that-project the-other-project 1.0 1.1 1.2 tags 1.0.0 1.0.1 1.1.0 1.2.0 1.2.1 

Donde trabajo, tenemos directorys "temp-branches" y "release-branches" en lugar de solo "branches". Por lo tanto, en su caso, las twigs del proyecto pasarían por debajo de temp-branches, y las twigs de liberación (creadas en el momento del lanzamiento, por supuesto) irían por debajo de las twigs de publicación.

Otra consideración importante es cuándo realizar una bifurcación y cuándo cerrar una sucursal, lo que depende de su cronogtwig de lanzamiento, pero también de cuánto time le llevará realizar la testing y la publicación. Según mi experiencia, esto requiere mucha administración en términos de garantizar que todos en el equipo sepan qué es el plan y cuándo usarlo, todo lo cual fue ayudado al documentarlo todo en un wiki de lanzamiento.

No es exactamente la respuesta que está buscando, pero creo que una vez que tenga la estructura orderada, para la cual ya ha recibido muchas buenas sugerencias, el próximo desafío es mantener al equipo informado y encaminado.

Las versiones son las mismas que las tags … ¿Tienes varios proyectos dentro de tu maletero? En ese caso, copyría las mismas carpetas dentro de las tags

Asi que

 trunk fooapp stuff... barapp stuff... tags fooapp 1.0.0 1.0.1 barapp 1.0.0