Mercurial: Repositorios granulares Vs Repositorios grandes y herramientas de terceros compartidas en el control de versión

Question

Escenario: Varios productos forman combinaciones de los proyectos más pequeños. Algunas versiones diferentes de cada producto en dev, release y maintennace (errores/parches/versiones menores).

La mayoría del equipo usa varias herramientas y bibliotecas de terceros para el desarrollo y la liberación (dos comunes son XUnit para desarrollador y AutoMapper en el producto). Son fanáticos de la versión que controla estas herramientas/bibliotecas donde tiene sentido.

No puedo entender la mejor manera de organizar la estructura en mercurial. En el estilo SVN central, me organizaría teniendo las herramientas de terceros como sus propios proyectos y luego teniendo pequeñas versiones para los proyectos que captarían el resultado de los otros proyectos, y luego un proyecto de lanzamiento que se construiría desde los proyectos construidos. Todo habría en una jerarquía,

(rama dev)

Root/dev/ProjectX/ 
Root/dev/ProjectY/ 
Root/dev/ThirdParty/XXX -- could be a 3rd party lib 
Root/dev/ThirdParty/YYY -- could be a 3rd party lib 

(rama 1)

Root/release1/ProjectX/ 
Root/release1/ProjectY/ 
Root/release1/ThirdParty/XXX 
Root/release1/ThirdParty/YYY 

(rama 2)

Root/release2/ProjectX/ 
Root/release3/ProjectY/ 
Root/release2/ThirdParty/XXX 
Root/release2/ThirdParty/YYY 

etc.

Aquí viene el problema, debido a la forma en que el desarrollador s mantener sus máquinas actualizadas (usando el administrador de paquetes NUGET) los elementos de terceros deben estar en la carpeta ThirdParty para garantizar que los desarrolladores no tengan que tener múltiples copias de estas bibliotecas para cada proyecto.

Mi pregunta es la siguiente:

Si implementan mercurial debe implementar una estrategia simmilar (grande repo) y el clon/sucursal aquí o en caso de que romper el repositorio decir a nivel de proyecto y el clon/rama de éstos. En este último caso, ¿tendrían un producto/versión branch/repo? Sé que preferirían un modelo distribuido si funciona mejor a largo plazo, incluso si el dolor de aprender un nuevo flujo de trabajo es difícil inicialmente.

He leído http://nvie.com/posts/a-successful-git-branching-model/ y una serie de artículos, pero todavía no estoy seguro de cómo organizar.

Answer 1

Básicamente, crea un repositorio por separado para cada producto, cada proyecto y cada biblioteca de terceros, y luego los combina según corresponda en subrepositories. En el servidor central (o servidores), probablemente establecer una estructura de pases desnudos como esto:

products/ProductA/ 
      ProductB/ 
      ProductC/ 
    projects/ProjectA/ 
      ProjectB/ 
      ProjectC/ 
thirdparty/ThirdPartyA/ 
      ThirdPartyB/ 
      ThirdPartyC/ 

esta manera usted tiene exactamente una copia de cada cesión temporal en el servidor central. No es necesario crear repositorios separados para cada sucursal, ya que mercurial puede contener múltiples sucursales en un depósito.

Luego, cuando alguien visita un Producto en su repositorio local, utiliza el mecanismo de subrepo para verificar también los árboles de trabajo para los proyectos apropiados y las bibliotecas de terceros. En el disco local, la estructura se verá así:

ProductA/ 
     ProjectA/ 
     ProjectB/ 
     ThirdParty/ 
        ThirdPartyC/ 

Esto se ve diferente que en el servidor central ya que no cuenta con árboles de trabajo, sólo punteros en las subrepos.