¿Son aceptables los troncos/ramas/etiquetas anidados?

Question

En un proyecto integrado reciente, hemos utilizado la siguiente estructura SVN:

project 
    branches 
    tags 
    trunk 
     electronics 
     software 
      branches 
      tags 
      trunk 

Como se puede ver, hay un/tag/directorio tronco ramas anidada para la parte de software. Esto fue bastante práctico para desarrolladores de software, ya que solo podían trabajar allí sin preocuparse por el resto.

Sin embargo, no parece correcto para mí, podría ser confusa debido a los múltiples niveles de ramificación, y las personas que trabajan más alto en la jerarquía pueden ser incomodados por toda la basura que tienen que descargar si comprobación la la parte superior del tronco ...

Así que estoy pensando en ir para un 1-tronco-único depósito para el próximo proyecto, y si los desarrolladores no quieren que las cosas no software, que sólo puede comprobación project/trunk/software y la rama de project/branches/br-1234/software , etc.

¿Qué opinas sobre troncos anidados? Pros & contras por favor!

Como una pregunta complementaria: ¿Las ramas/etiquetas siempre deben ser copias del tronco (u otra rama), o es aceptable hacer una rama de un subdirectorio de tronco?

Answer 1

Troncales anidados me indican una recopilación de código con un ciclo de vida diferente al código padre. Consideraría estos proyectos conceptualmente separados. Además, tenga en cuenta que su repositorio puede tener múltiples proyectos de alto nivel, lo que debería reducir el mantenimiento de un repositorio separado para cada proyecto. Considero el uso de repositorios separados cuando necesito una configuración separada del nivel de repositorio: accesibilidad, protocolo de transporte, autenticación/autorización (aunque estos se pueden configurar dentro de un repositorio).

main_project 
    branches 
    tags 
    trunk 
     electronics 
software 
    branches 
    tags 
    trunk 

Posteriormente, se podría añadir una carpeta cualquiera libs a main_project/trunk para contener una forma compilada de software, o tal vez considere el uso de una referencia externa SVN para que apunte a software/trunk desde dentro main_project/trunk.

También "major_project" ahora podría llamarse mejor "electronics", en cuyo caso quitaría la carpeta adicional "electronics" en "trunk".

Answer 2

Definitivamente no sería ideal, se vuelve muy confuso muy rápido. Dado que en realidad no ocupa mucho/ningún espacio de almacenamiento para crear ramas/etiquetas, no hay muchas razones para terminar con una estructura como esta. Sucursal en el nivel de proyecto solo en mi humilde opinión.

Answer 3

Aceptable a ¿Quién? No hay un Papa de la subversión, y cada organización es libre de hacer lo que mejor le acomode. La versatilidad de SVN que te da esa libertad es algo bueno.

Answer 4

La respuesta corta a todas sus preguntas: no.

estoy imaginando un Abbott & Costello "quién está en primer lugar" la discusión: "Me lo fusionó con el tronco" "¿Qué tronco?" "el tronco de la rama de integración" "¿Entonces el tronco está actualizado?" "¿Qué baúl?"

Los nuevos miembros del equipo tendrán dificultades para adaptarse a un esquema que contradice su experiencia previa. Tendrán que buscar documentación interna o hacer preguntas sobre algo que debería ser realmente simple.

Muchas herramientas & IDEs son mucho más onerosas para trabajar si se utiliza un diseño no estándar.

De mayor preocupación es su segunda pregunta sobre los subconjuntos de ramificación/etiquetado del tronco o una rama. con copias baratas de subversiones, no hay ganancia de espacio o tiempo para ramificar/etiquetar un subconjunto, y lo que es más importante, su svn: mergeinfo será mucho menos útil si las personas se ramifican/etiquetan en cualquier lugar que no sea el nivel superior.