Organización de proyectos SVN: por módulo o por proyecto

Question

Tengo un repositorio de subversión que contiene un número de subcarpetas, correspondiente a las diversas aplicaciones, archivos de configuración, DLL, etc. (los llamaré 'módulos') que componen mi proyecto. Ahora estamos comenzando a "ramificar" en varios proyectos relacionados. Es decir, cada proyecto de alto nivel utilizará varios de los módulos, posiblemente ligeramente modificados de un proyecto a otro. El número de proyectos es más pequeño (~ 5) que el número de módulos (~ 20)

Ahora estoy tratando de encontrar la forma de organizar el repositorio. ¿Tiene sentido mantener las subcarpetas de nivel superior módulo por módulo, con subcarpetas para cada proyecto? O debería ser el nivel superior para cada proyecto, con cada proyecto tiene sus propias subcarpetas módulo:

repo:

module 1 
    Project 1 
    Project 2 
    ... 

    Project 5 
module 2 
    Project 1 
    .... 
    Project 5 
.... 
module 20 
    Project 1 
    ... 
    Project 5 

-o-

repo:

Project 1 
    module 1 
    module 2 
    ... 
    module 20 
Project 2 
    module 1 
    module 2 
    ... 
    module 20 
... 
Project 5 
    module 1 
    module 2 
    ... 
    module 20 

Answer 1

Creo que su uso de "alto nivel" para describir lo que es un proyecto sugiere que debe tener una configuración de proyectos/módulos.

Sin embargo, podría tener una configuración de Módulos y Proyectos, es decir, están en el mismo nivel en el repositorio SVN. Sus proyectos pueden confiar en los módulos y, si es posible, los proyectos pueden proporcionar implementaciones de acciones específicas, convirtiendo el módulo en un módulo base con implementaciones predeterminadas pero anulables.

Answer 2

Lo organizaría por proyectos ENTONCES por módulos (su segundo ejemplo). La razón principal es porque hay más sobrecarga en la gestión de un proyecto, al menos para mí, que la gestión de módulos.

Cada proyecto diferente necesita su propia configuración del script de creación, archivo de propiedades, etc., y es mucho más fácil hacer un seguimiento de 5 copias de trabajo en el equipo de 20.

Answer 3

Yo prefiero la primera uno.

Si bien se necesita un esfuerzo extra por depósito para mantener, me gusta que mis números de revisión tengan sentido para el proyecto.

es decir, nuestro producto estrella tiene una revisión de 48123, nuestro nuevo proyecto tiene una revisión de 31. Si tiene dependencias entre repositorios, puede usar svn externals.

Answer 4

Parecería mejor organizar por Proyecto en el nivel superior, ya que va a querer pagar una sucursal completa y tener una copia de trabajo para el proyecto. Si organiza por módulo, tendrá que hacer varias comprobaciones (una para cada módulo que esté utilizando) con el fin de construir su proyecto hasta un punto en el que sea utilizable.

Podría tener sentido para mantener los dos proyectos y módulos separados, Ej:

Projects 
    Project 1 
    Project 2 
    ... 
Modules 
    Module 1 
    Module 2 
    ... 

Si utiliza que, en combinación con SVN externals y/o vendor branches, se podía soportar diferentes ramas para sus proyectos que necesitan diferentes versiones de módulos, pero todavía se benefician de tener una única fuente de módulo cuando los proyectos comparten la misma versión de un módulo.

Answer 5

Tendería a organizar por proyecto, pero ahora siempre.Si tiene aspectos de control de acceso de su código, organícelos en minimice la administración de permisos; esto también podría resultar en una organización por equipo del repositorio.

Dicho sea de paso: Parece que espera trabajar en un gran repositorio, lo que creo que es inteligente, porque significa un mejor manejo de la historia: tan pronto como mueve cosas entre repositorios, pierde historia. En otras palabras, no estoy de acuerdo con el consejo de Ben Scheirman sobre esto.