¿Mejores prácticas para los sub-módulos de características del proyecto con Mercurial y Eclipse?

Question

Tengo un par de proyectos ANT para varios clientes diferentes; la estructura de directorios que tengo para mis proyectos es el siguiente:

L___standard_workspace 
    L___.hg 
    L___validation_commons-sub-proj <- JS Library/Module 
    | L___java 
    | | L___jar 
    | L___old_stuff 
    | L___src 
    | | L___css 
    | | L___js 
    | |  L___validation_commons 
    | L___src-test 
    |  L___js 
    L___v_file_attachment-sub-proj <- JS Library/Module 
    | L___java 
    | | L___jar 
    | L___src 
    | | L___css 
    | | L___js 
    | L___src-test 
    |  L___js 
    L___z_business_logic-sub-proj <- JS Library/Module 
    | L___java 
    | | L___jar 
    | L___src 
    |  L___css 
    |  L___js 
    L____master-proj    <- Master web-deployment module where js libraries are compiled to. 
     L___docs 
     L___java 
     | L___jar 
     | L___src 
     |  L___AntTasks 
     |   L___build 
     |   | L___classes 
     |   |  L___com 
     |   |   L___company 
     |   L___dist 
     |   L___nbproject 
     |   | L___private 
     |   L___src 
     |    L___com 
     |     L___company 
     L___remoteConfig 
     L___src 
     | L___css 
     | | L___blueprint 
     | | | L___plugins 
     | | | | L___buttons 
     | | | | | L___icons 
     | | | | L___fancy-type 
     | | | | L___link-icons 
     | | | | | L___icons 
     | | | | L___rtl 
     | | | L___src 
     | | L___jsmvc 
     | L___img 
     | | L___background-shadows 
     | | L___banners 
     | | L___menu 
     | L___js 
     | | L___approve 
     | | L___cart 
     | | L___confirm 
     | | L___history 
     | | L___jsmvc 
     | | L___mixed 
     | | L___office 
     | L___stylesheets 
     | L___swf 
     L___src-standard 

Dentro de la copia de trabajo, los módulos de compilar el sub-proyecto en un único archivo JavaScript que se coloca en el directorio Javascript del proyecto principal.

Por ejemplo, los directorios:

• validation_commons-sub-proj
• v_file_attachment-sub-proj
• z_business_logic-sub-proj

... todo se combinan y minified (una especie de compilado similares) en una diferente Nombre de archivo Javascript en el directorio _master-proj/js; y en el paso final, el _master-proj se compila para implementarse en el servidor.

Ahora, en cuanto a la forma en que me gustaría configurar esto con hg, lo que me gustaría hacer es clonar el proyecto maestro y sus subproyectos desde sus propios repositorios de línea base en un Copia de trabajo del cliente, para que los módulos se puedan agregar (usando hg) a la copia de trabajo de un cliente en particular.

Además, cuando realizo algunos cambios/corrijo errores en la copia de trabajo de un cliente, me gustaría poder enviar los cambios/correcciones de errores al repositorio de línea base del proyecto principal/subproyecto , con el objetivo de eventualmente colocar los cambios/correcciones en las copias de trabajo de otros clientes que podrían contener los mismos errores que deben corregirse.

De esta manera podré utilizar las mismas correcciones de errores en diferentes clientes.

Sin embargo ... No estoy seguro de la mejor manera de hacerlo utilizando hg y Eclipse.

I que puede usar hg's Convert Extension para dividir un subdirectorio en un proyecto separado utilizando la opción --filemap.

Sin embargo, todavía estoy un poco confundido en cuanto a si sería mejor usar el Convert Extension o si sería mejor simplemente alojar cada uno de los módulos en su propio repositorio y revisarlos en un solo espacio de trabajo para cada cliente

Answer 1

Sí, parece que subrepos son lo que usted está buscando, pero creo que tal vez es la respuesta correcta a la pregunta equivocada y tengo la fuerte sospecha de que se encontrará con similares issues that occur when using svn:externals

lugar que recomendaría que "publica" sus archivos JS combinados y minificados en un artefact repository y usa un administrador de dependencias como Ivy para extraer versiones específicas de sus artefactos en su proyecto maestro. Este enfoque le brinda un control mucho mayor sobre las versiones de subproyectos que utiliza su proyecto principal.

Si necesita corregir errores en un subproyecto para un cliente en particular, puede hacer las correcciones en la línea principal para ese subproyecto, publicar una nueva versión (idealmente a través de automated build pipeline) y actualizar su maestro proyecto para usar la nueva versión. Oh, ¿quisiste probar la nueva versión con su proyecto maestro antes de publicar?En ese caso, antes de presionar su solución, combine y minimice su subproyecto localmente, publíquelo en un local repository y haga que el proyecto maestro del cliente obtenga esa versión para su prueba.