¿Cómo se estructura su repositorio SVN?

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 usas repositorio y por qué?

Answer 1

El capítulo Repository Administration del SVN book incluye una sección en Planning Your Repository Organization que describe diferentes estrategias y sus implicaciones, particularmente the implications of the repository layout on branching and merging.

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 proyecto único, pero puede tratarse de varios proyectos que pertenecen juntos (es decir, lo que pondría en una solución en Visual Studio). De esta forma, tienes todo lo 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 ramas.

Pero al final, las personas usan las dos formas. Haz lo que quieras, pero cuando lo hayas decidido, intenta quedarte con él :)

Como una adición: tenemos repositorios 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 único cliente a la vez o proporcione el código fuente de cualquier cosa que el cliente le pertenezca sin pelear con SVN.

Answer 3

que 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 por separado en depósitos separados. El uso de svn:externals facilita la administración de proyectos de bibliotecas de códigos que se comparten entre dos o más proyectos de aplicaciones.

Answer 4

Utilizamos la configuración B. Beause es más fácil verificar/etiquetar varios proyectos a la vez. En svn 1.5, es posible a través de un checkout disperso, pero no de una operación de un solo clic. Desea utilizar la configuración B, si algunos proyectos tienen dependencias ocultas entre ellos.

Answer 5

Utilizamos

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

Qué estoy empezando a lamentar. 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 un equipo de proyecto creó el producto QUUX. El año que viene, ese equipo está disperso y una o dos personas mantienen QUUX. El próximo año, habrá dos grandes proyectos de expansión QUUX.

Dada esa línea de tiempo, ¿QUUX debería aparecer en tres repositorios de proyectos? No, QUUX es independiente de cualquier proyecto en particular. Es cierto que los proyectos sí tienen productos de trabajo (documentos, atrasos, etc.) que son parte del trabajo realizado, pero que no son el objetivo real del trabajo. De ahí los repositorios "projectX" para ese material, cosas que a nadie le importará después de que el proyecto esté 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 versiones 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, se trataba de tres piezas de software con superposiciones extrañas y redundancia.

Answer 6

Personalmente utilizo estructura siguiente repositorio:

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

También hay un diagram ilustra cómo se utilizan esos directorios. También hay un enfoque de numeración de versión específica que uso. Juega un papel importante en la estructuración de repositorios. Recientemente, he desarrollado una capacitación dedicada a Software Configuration Management donde describo el enfoque de numeración de versiones y por qué exactamente esta estructura de repositorio es la mejor. Aquí están presentation slides.

También está mi answer en el question sobre 'Multiple SVN Repositories vs single company repository'. Puede ser útil siempre que aborde este aspecto de la estructuración del repositorio en su pregunta.