¿Es una buena idea poner todos los proyectos en el mismo baúl?

Question

Entendemos el valor por defecto y la organización repositorio SVN por lo general se recomienda, en caso de tener varios proyectos, es algo como esto:

root/projectA/(trunk, branches, tags) 
root/projectB/(trunk, branches, tags) 
... 

Nuestros proyectos tienen una gran cantidad de interdependencia, y que exigirían un uso extenso de SVN : Externals entre ellos, teniendo en cuenta que no hacemos referencia dll a proyectos internos, preferiríamos ver su código fuente en lugar de trabajar con binarios.

El uso excesivo de elementos externos, al diversificar los cambios, sincronizar los cambios, puede convertirse en una experiencia compleja y propensa a errores, por lo que el equipo no confió en absoluto en esta solución.

Así que un miembro del equipo sugirió algo que todos pensamos que podría ser una mejor solución: poner todos los proyectos en el mismo tronco.

Al principio, reconocimos algunos problemas con este enfoque, pero en general estamos de acuerdo en que estos problemas se basan en situaciones hipotéticas que muy probablemente nunca experimentaríamos.

¿Ve algunos problemas serios que podamos tener con esta solución?

Answer 1

Hacemos esto en nuestra empresa y hemos tenido mucho éxito.

Tenemos 3 directorios de nivel superior:

• etiquetas
• ramas
• tronco

y entonces tenemos cada proyecto como un subdirectorio de esos.

Aun así ramificamos a nivel de proyecto y todavía usamos svn: externals. Pero si tuviéramos un árbol fuente más pequeño, nos ramificaríamos en el nivel troncal y no usaríamos svn: extenrals.

Es agradable poder tener la cajuela de todos los proyectos en el mismo lugar. Puedes hacer una copia de seguridad, puedes verificarlo todo y tienes todas las cosas más recientes juntas. No se pierde la ubicación única para todas las ramas, ni ubicación única para todas las etiquetas, ya sea porque están todos en los subdirectorios de/ramas/Projectx y/tags/Projectx

Problemas con svn: externals:

Si sus proyectos no son extremadamente GRANDES, podría ramificar todo el tronco cada vez y evitar todos los problemas con svn: externals.

El problema con svn: externals es que cuando haces una rama, no crea automáticamente una rama para cada uno de los svn: externos para ti. Esto es un problema porque con el tiempo todas sus sucursales antiguas no podrán compilarse a medida que su troncal se actualice. Otro problema es que si modificas una rama en un svn: externo, todas tus otras ramas se rompen.

Otro problema con svn externals es que cuando haces un svn: log en el nivel raíz, no ves ningún cambio desde svn externals.

Esperemos que un día svn externals será reparado para resolver los problemas anteriores, pero hasta ese día la ramificación y svn: externals es una pesadilla absoluta.

Answer 2

Lo que ha hecho es lo que he configurado en mi empresa, y también se menciona como un "diseño muy común" en el tema svnbook, Strategies for Repository Deployment.

Nada de malo en eso.

Answer 3

a "poner todos los proyectos en un mismo tronco":

Desde mi experiencia esto no es una buena idea - ya que cada proyecto tiene su propia historia y los cambios y, a menudo los proyectos son/serán mantenidos por diferentes desarrolladores. Esto puede generar conflictos, incluso si usted declara que actualmente los proyectos interfieren fuertemente.

¿Por qué no usa etiquetas comunes (con hitos como nombres) para todos sus proyectos para garantizar una misma base de código y un script de construcción, que puede verificar los proyectos (troncos) automágicamente? Es más trabajo, pero como es habitual en OOP (capsulación), también preferiría dividir los proyectos en directorios SVN separados.

Pero: juntar un montón de pequeñas bibliotecas y aplicaciones en un directorio común bajo la misma troncal no es problema (ver "aplicaciones" y "herramientas" en mi ejemplo a continuación) - así que tal vez los "proyectos pequeños" pueden permanecer en el tronco compartido/grande.

Aquí, como ejemplo, mi estructura de directorios de SVN:

/projects/ 
/projects/CustomerA/ 
/projects/CustomerA/ProjectX/ 
/projects/CustomerA/ProjectX/trunk/ 
/projects/CustomerA/ProjectX/tags/ 
/projects/CustomerA/ProjectX/branches/ 
/thirdparty/ 
/thirdparty/ExtLibY/ 
/thirdparty/ExtLibZ/ 
/tools/ 
/tools/trunk/ 
/tools/tags/ 
/tools/branches/ 
/apps/ 
/apps/trunk/ 
/apps/tags/ 
/apps/branches/ 

Así que toda la materia externa se almacena en/thirdparty/y todos los componentes internos (proyectos, herramientas, aplicaciones) tienen los subdirectorios:

/trunk/ 
/tags/  
/branches/ 

... como se aconseja en el libro de Subversion y en la publicación anterior.

Incluso si eso parece un poco demasiado esfuerzo a primera vista, realmente vale la pena, especialmente cuando su base de código crece.

ciao, Chris

Answer 4

¿Se ve algunos problemas graves que pueden tener con esta solución?

• Su solución sólo funciona todo el tiempo que puede poner todo en un solo repositorio.

  Esto significa que todo el repositorio tiene que caber en un solo disco (o grupo de almacenamiento) en el futuro previsible. Se aplican consideraciones similares para otros recursos del servidor como el ancho de banda de E/S de red y disco.

  La división posterior del repositorio requerirá una gran revisión general de toda su configuración, y puede causar dolores de cabeza cuando necesite reconstruir o ramificar versiones antiguas.

• Su solución sólo funciona si usted no tenga que limitar los permisos de lectura/escritura sobre una base por usuario

  Si tiene que dar permiso de lectura/escritura para ProjectA, usted realmente tiene para dar permiso para/trunk/projectA, y/branch1/projectA, y/branch2/projectA etc.

  La ramificación se convierte en un proceso de gran peso que requiere muchos ajustes de permisos. Despídase de feature branches.