subversion - svn windows

¿Cuál es un buen diseño de repositorio para lanzamientos y proyectos en Subversion? (7)

Tenemos el diseño estándar de tronco / ramas / etiquetas de Subversion. Tenemos varias sucursales para proyectos a mediano y largo plazo, pero ninguna hasta ahora para un lanzamiento. Esto se acerca rápido.

Deberíamos:

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

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 "rama 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 etiquetas 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 rama de publicación se mantiene abierta para soporte, seguridad y corrección de errores, y las versiones menores son etiquetadas y liberadas de esto.

Una vez que una versión particular ya no es compatible, cerramos la rama. 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 plazo o masivos que romperán el sistema por largos períodos de tiempo también reciben su propia rama, 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 rama de branches / 3.1-Release y fusionamos commits individuales desde el trunk según nos parezca oportuno (nuestras ramas de lanzamiento usualmente solo reciben las correcciones más importantes del principal rama de desarrollo).

Por lo general, esta rama de versión vive a través de las fases de prueba 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 paquete de descarga, es etiquetar la rama de publicación como liberada, por lo que puede reconstruir fácilmente desde exactamente la misma revisión si lo necesita más adelante.

Carl

Las versiones son las mismas que las etiquetas ... ¿Tienes varios proyectos dentro de tu maletero? En ese caso, copiaría las mismas carpetas dentro de las etiquetas

Asi que

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

Recomiendo el siguiente diseño, por dos razones: - todo lo relacionado con un proyecto dado se encuentra dentro de la misma parte del árbol; hace que sea más fácil de entender para las personas - el manejo de permisos puede ser más fácil de esta manera

Y dicho sea de paso: es una buena idea con pocos repositorios, 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 archivos entre repositorios, a menos que realice una acción especial y algo complicada). En la mayoría de las configuraciones, solo debe haber dos repositorios: el repositorio principal y un repositorio 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

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

En este caso, necesitamos etiquetar, por ejemplo, 1.0.0, pero también bifurcar, por ejemplo, 1.0. Mi preocupación es mezclar ramas de proyectos y ramas 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 directorios "temp-branches" y "release-branches" en lugar de solo "branches". Por lo tanto, en su caso, las ramas del proyecto pasarían por debajo de temp-branches, y las ramas de liberación (creadas en el momento del lanzamiento, por supuesto) irían por debajo de las ramas 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 cronograma de lanzamiento, pero también de cuánto tiempo le llevará realizar la prueba y la publicación. Según mi experiencia, esto requiere mucha administración en términos de asegurar que todos en el equipo sepan qué es el plan y cuándo usarlo, todo lo cual fue ayudado documentando todo en un wiki de lanzamiento.

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