Estructura de carpeta de repository y construcción automática desde esa estructura

Estamos actualizando nuestro control de código fuente (lo más probable es que Vault ) en el trabajo y nos estamos moviendo a la metodología de bifurcación, y estamos teniendo algunos problemas con el uso de la estructura de carpetas para usar.

Tenemos la intención de utilizar el tronco como la línea de desarrollo, y una twig será un lanzamiento y correcciones de errores para esa versión.

Hemos creado dos estructuras de carpetas, y quería saber cuáles eran las ventajas y desventajas de cada una de ellas:

Projects |-> Trunk |-> Data Access |-> Business |-> Desktop |-> Website |-> Branches |-> Branch 01 |-> Data Access |-> Business |-> Desktop |-> Website 

y

 Projects |-> Data Access |-> Trunk |-> Branches |-> Branch 01 |-> Business |-> Trunk |-> Branches |-> Branch 01 |-> Desktop |-> Trunk |-> Branches |-> Branch 01 |-> Website |-> Trunk |-> Branches |-> Branch 01 

Si usamos un bloque de control de fuente en la máquina de compilation ( cruisecontrol.net ) con la primera solución, podemos decir:

 <path>$\Projects\trunk\</path> 

Construir una twig sería bastante similar, pero ¿es posible recoger la twig más nueva en la carpeta de branches ? de lo contrario, tendríamos que editar la configuration de ccnet para cada lanzamiento.

Si se utilizara la segunda metodología (mucha gente sugiere este método) ¿cómo captaría la máquina de construcción todos los proyectos relevantes? algo como esto tal vez:

 <path>$\Projects\*\trunk\</path> 

si algunos proyectos han sido ramificados pero otros no, ¿cómo puedo hacer para get el tronco cuando no existe una twig (si esto es posible).

¿Obtendría todos los troncos, y luego sobrescribiría con las twigs? ¿Sería un error si intentara acceder a una sucursal inexistente?

La primera metodología es muy confiable. Usted sabe exactamente lo que está enviando (porque tiene un punto de input para cada versión: ya sea el tronco o una twig / label).

Veo varios problemas con la segunda metodología:

  1. todos los proyectos deben ramificarse / labelrse al mismo time
  2. las fusiones deben hacerse para cada proyecto individualmente

Ambas opciones son posibles, pero considero que la primera es la alternativa más fácil pero también la más segura.

Dado que el website es probablemente independiente de los lanzamientos (si publica desde una sucursal creada en 2007, no toma el website de 2007, sino el 2009).

 Project | +- Trunk Website | +- Trunk 

Al final, escribí un complemento de control de fuente (usando la API de Vault) para permitirme especificar algunos extras en la label <folder> :

 <folder>$/branches/%latest%</folder> 

recuperará la última twig en la carpeta de twigs.

Prefiero repositorys estructurados, muy organizados, independientes y detallados. Hay un diagtwig que ilustra el enfoque general (ideal) del process de mantenimiento del repository. Por ejemplo, mi estructura inicial de repository (debe tener cada repository de proyecto) es:

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