¿Cómo estructurar su repositorio SVN? [cerrado]

Question

¿Qué es mejor?

A:

server:1080/repo/projectA/trunk/...
                          branches/branch1
                          branches/branch2
                          branches/branch3
                          tags/tag1/...
                          tags/tag2/...
server:1080/repo/projectB/trunk/...
                          branches/branch1
                          branches/branch2
                          branches/branch3
                          tags/tag1/...
                          tags/tag2/...

B:

server:1080/repo/trunk/projectA/...
                 branches/projectA/branch1
                 branches/projectA/branch2
                 branches/projectA/branch3
                 tags/projectA/tag1/...
                 tags/projectA/tag2/...
server:1080/repo/trunk/projectB/trunk/...
                 branches/projectB/branch1
                 branches/projectB/branch2
                 branches/projectB/branch3
                 tags/projectB/tag1/...
                 tags/projectB/tag2/...

¿Qué estructura de repositorio utiliza y POR QUÉ?

Answer 1

El Repository Administration del capítulo SVN book incluye una sección sobre Planificación de su organización de repositorio que describe diferentes estrategias y sus implicaciones, particularmente las implicaciones del diseño del repositorio en la ramificación y fusión .

Answer 2

Usamos A, porque el otro no tenía sentido para nosotros. Tenga en cuenta que un " proyecto " con respecto a SVN no es necesariamente un solo proyecto, sino que puede haber varios proyectos que pertenezcan juntos (es decir, lo que pondría en una Solución en Visual Studio). De esta manera, tienes algo relacionado agrupado. Todas las ramas, etiquetas y el tronco de un proyecto específico. Tiene perfecto sentido para mí.

Agrupar por rama / etiqueta en su lugar no tiene sentido para mí, porque las ramas de diferentes proyectos no tienen nada en común, excepto que todas son sucursales.

Pero al final, la gente usa ambas formas. Haz lo que quieras, pero cuando hayas decidido, trata de seguir con esto :)

Como adición: tenemos repositorios separados por cliente, es decir, todos los proyectos para un cliente están en el mismo repositorio. De esta manera usted puede, por ejemplo. haga copias de seguridad de un solo cliente a la vez, o proporcione el código fuente de todo lo que el cliente posee sin pelearse con SVN.

Answer 3

Sugeriría una opción C:

server:1080/projectA/trunk/...
                     branches/branch1
                     branches/branch2
                     branches/branch3
                     tags/tag1/...
                     tags/tag2/...
server:1080/projectB/trunk/...
                     branches/branch1
                     branches/branch2
                     branches/branch3
                     tags/tag1/...
                     tags/tag2/...

Prefiero mantener proyectos separados en repositorios separados. El uso de svn: externals facilita la administración de proyectos de biblioteca de códigos que se comparten entre dos o más proyectos de aplicación.

Answer 4

Usamos la configuración B. Porque es más fácil revisar / etiquetar múltiples proyectos a la vez. En svn 1.5 es posible a través de un pago disperso, pero no con una operación de un solo clic. Desea utilizar la configuración B, si algunos proyectos tienen dependencias ocultas entre ellos.

Answer 5

Usamos

/repos/projectA/component1/trunk - branches - tags
/repos/projectA/component2/trunk - branches - tags
/repos/projectB/component3/trunk - branches - tags
/repos/projectB/component4/trunk - branches - tags

Lo que estoy empezando a arrepentir. Debería ser más plano. Esto sería mejor.

/repos/projectA/trunk - branches - tags
/repos/projectB/trunk - branches - tags
/repos/component1/trunk - branches - tags
/repos/component2/trunk - branches - tags
/repos/component3/trunk - branches - tags
/repos/component4/trunk - branches - tags

¿Por qué? Los productos (componentes, software terminado) duran para siempre. Los proyectos van y vienen. El año pasado solo hay un equipo de proyecto que crea el producto QUUX. El próximo año, ese equipo se dispersa y una o dos personas mantienen QUUX. El próximo año, habrá dos grandes proyectos de expansión de QUUX.

Dado ese cronograma, ¿debería aparecer QUUX en tres repositorios de proyectos? No, QUUX es independiente de cualquier proyecto en particular. Es cierto que los proyectos tienen productos de trabajo (documentos, trabajos pendientes, etc.) que son parte de la realización del trabajo, pero no son el objetivo real del trabajo. De ahí el " proyectoX " repositorios para ese material: cosas que a nadie le importará después de que el proyecto haya terminado.

Trabajé en un producto que tenía tres equipos. Gran problema con la coordinación del trabajo porque cada proyecto gestionó su repositorio de forma independiente. Hubo lanzamientos entre equipos y coordinación entre equipos. Al final del día, se suponía que era una pieza de software. Sin embargo, como puede adivinar, fueron tres piezas de software con superposiciones y redundancias extrañas.

Answer 6

Personalmente uso la siguiente estructura de repositorio:

/project
    /trunk
    /tags
        /builds
            /PA
            /A
            /B
        /releases
            /AR
            /BR
            /RC
            /ST
    /branches
        /experimental
        /maintenance
            /versions
            /platforms
        /releases

También hay un diagrama que ilustra cómo se utilizan esos directorios . También hay un enfoque de numeración de versión específico que utilizo. Juega un papel importante en la estructuración del repositorio. Recientemente, he desarrollado una capacitación dedicada a la gestión de la configuración del software, en la que describo el enfoque de numeración de versiones y por qué exactamente esta estructura de repositorio es la mejor. Aquí hay diapositivas de presentación .

También está mi answer en la question sobre 'Repositorios de SVN múltiples vs repositorio de una sola compañía'. Podría ser útil siempre que aborde este aspecto de la estructura del repositorio en su pregunta.