¿Cuándo debería un proyecto de varios módulos dividirse en árboles de repositorio separados?

Question

Actualmente tenemos un proyecto con un diseño de depósito de la subversión de la norma:

./trunk
./branches
./tags

Sin embargo, como nos estamos moviendo en el camino de OSGi y una proyecto modular, hemos acabado con:

./trunk/bundle/main
./trunk/bundle/modulea
./trunk/bundle/moduleb ./tags/bundle/main-1.0. 0
./tags/bundle/main-1.0.1
./tags/bundle/modulea-1.0.0

El 'construir' es todavía bastante monolítica en la que se construye todos los módulos en secuencia, aunque' estoy empezando a preguntarse si debemos refactorizar la acumulación/repositorio a algo más parecido a:

./bundle/main/trunk
./bundle/main/tags/main-1.0.0
./bundle/main /tags/main-1.0.1
./bundle/modulea/trunk
./bundle/modulea/tags/modulea-1.0.0

En este patrón, me imagino cada módulo construyéndose, y almacenando su binario en un repositorio (maven, ivy u otra ruta del repositorio de subversión).

¿Existen pautas o 'mejores prácticas' sobre los diseños de proyectos una vez que se hace modular?

Answer 1

El libro de Subversion contiene dos secciones de esta:

• Repository Layout
• Planning Your Repository Organization

una entrada de blog sobre el tema: "Subversion Repository Layout"

La respuesta corta, sin embargo: mientras que su el kilometraje variará (cada situación es individual), su esquema /bundle/<project>/(trunk|tags|branches) es bastante común y lo hará probablemente funcione bien para ti

Answer 2

Esto se parece mucho a la preferencia personal, pero encuentro la siguiente estructura adecuada para grandes proyectos que constan de varios módulos:

 
branches 
    project-name 
    module1 
     branch-name 
    module2 
     possibly-another-branch-name 
    branch-name-on-a-higher-level-including-both-modules 
     module1 
     module2 
tags 
    ... (same as branches) 
trunk 
    project-name 
    module1 
    module2 

he también a menudo se utiliza la estructura en grandes depósitos que contienen muchos proyectos, porque mantener todos los proyectos en el mismo repositorio hace que los proyectos de referencia cruzada y el código compartido entre ellos — con historial — sean más fáciles.

Me gusta utilizar la estructura con carpetas troncales raíz, etiquetas y ramas desde el principio porque en mi experiencia (con repositorios grandes que contienen muchos proyectos), muchos subproyectos y módulos nunca tendrán etiquetas o ramas separadas, por lo que no es necesario crear la estructura de carpetas para ellos. También hace que sea más fácil para los desarrolladores verificar el tronco completo del repositorio y no obtener todas las etiquetas y ramas (que no necesitan la mayor parte del tiempo).

Supongo que esto es una cuestión de política de proyecto o compañía. Si tiene un repositorio para cada proyecto o es probable que un desarrollador determinado trabaje en un solo proyecto en el repositorio a la vez, es posible que el tronco enraizado no tenga tanto sentido.

Answer 3

He respondido una pregunta similar en un StackOverflow Version Control Structure question. En realidad, encaja aquí aún mejor, ya que desarrollamos mucho OSGi y tenemos muchos paquetes. Debo hacerme eco de los comentarios de Anders Sandvig: mantenga trunk/tags/branches en el nivel raíz ya que solo ramificará un conjunto limitado de módulos. Tampoco interfiere con la creación individual de módulos.

No copiaré la respuesta que hice antes, pero es completamente relevante para esta pregunta.

Answer 4

Sólo mis dos centavos ...

sólo quiero hacer hincapié en el comentario en la documentación de SVN (ya citado en otra respuesta, mismo hilo) http://svnbook.red-bean.com/en/1.4/svn.reposadmin.planning.html#svn.reposadmin.projects.chooselayout

El extracto hace referencia a la siguiente estructura: / tronco/ calc/ calendario/ hoja de cálculo/ ... etiquetas/ calc/ calendario/ hoja de cálculo/ ... ramas/ calc/ calendario/ hoja de cálculo/

"No hay nada particularmente incorrecta sobre un diseño de este tipo, sino que puede o puede no parecer tan intuitivo para los usuarios. Especialmente en situaciones grandes y de proyectos múltiples con muchos usuarios, esos usuarios tienden a estar familiarizados con solo uno o dos de los proyectos en el repositorio. Pero los proyectos como hermanos-rama tienden a restar importancia a la individualidad del proyecto y a enfocarse en todo el conjunto de proyectos como una sola entidad. Eso es un problema social sin embargo. Nos gusta nuestra disposición sugerida originalmente por razones puramente prácticas: es más fácil preguntar (o modificar, o migrar en otro lugar) la historia completa de un solo proyecto cuando hay una sola ruta de repositorio que contiene toda la historia: pasado, presente, etiquetado y . ramificada para ese proyecto y ese proyecto solo"

por mi, estoy de acuerdo con mucha fuerza con esto y prefiere la siguiente distribución: / utils/ calc/ troncales/ etiquetas/ ramas/ calendario/ tronco/ etiquetas/ ramas/ ... oficina/ hoja de cálculo/ tronco/tags/ ramas/

La razón son simplemente que su práctico para etiquetar un conjunto de proyectos completa cuando uno quiere etiquetar sólo un subconjunto específico.

Usemos un ejemplo: si project-1 depende de moduleA v1.1 y moduleB v2.3, no quiero que aparezca el nuevo moduleA v2.x en las etiquetas. De hecho, cuando regrese algunos días/semanas/meses después a esta publicación etiquetada, me veré forzado a abrir el descriptor del paquete en la versión etiquetada del proyecto-1 para leer la versión del móduloA realmente requerida.

Además, si tengo que hacer una copia de seguridad específica de las fuentes de esta versión en un CD, solo quiero exportar esta etiqueta sin descargar cientos de megabytes de cosas no relacionadas.

Era solo mis dos centavos.