Mercurial con múltiples proyectos

Tengo un par de proyectos con diferentes ciclos de publicación en mi repository SVN. Las versiones se crean utilizando la estructura de tags clásica en SVN. Cuando hay errores para corregir en los lanzamientos, se crea una twig a partir de una label, el error se corrige y luego se fusiona desde allí en el tronco.

Ahora, por varias razones, quiero pasar de SVN a mercurial con un sitio de inserción central.

Pregunta: ¿Cuál es la mejor manera de mercurial para organizar proyectos múltiples que comparten poco código entre ellos? ¿Debo crear varios sitios de inserción, uno para cada proyecto?

Incluya en la respuesta una descripción sobre cómo recrear mi label de liberación, bifurcación de corrección de errores, … con su versión preferida del layout del repository.

Editar: me gustaría instalar la menor cantidad de extensiones posible.

Edit2:

Dado este layout de SVN:

. |-- project-a | |-- branches | | |-- 1.x | | `-- feature-1 | |-- tags | `-- trunk `-- project-b |-- branches |-- tags | |-- 1.0 | `-- 1.1 `-- trunk 

(gracias @bendin! :))

¿Es mejor trabajar con varios repositorys de inserción de hg

 project_a-trunk project_a-1.x project_a-feature-1 project_b-trunk 

para las twigs. Las tags se pliegan en la twig correspondiente.

¿O prefieres ir con dos repositorys de inserción en este ejemplo?

 project_a project_b 

con twigs nombradas y por lo tanto múltiples cabezas dentro de un repo.

La ventaja que veo con los repos de encabezados múltiples es que no tengo que ir a search una label en varios repositorys. La desventaja que veo es que el libro de hg parece desalentar los repos de cabeza múltiples. ¿Qué harías / harías?

Algunos repositorys de subversión agruparán elementos lógicamente no relacionados (es decir, proyectos con diferentes numbers de versión y ciclos de publicación) en un tronco:

 . |-- branches | |-- project-a-1.x | `-- project-a-feature-1 |-- tags | |-- project-a-1.0 | |-- project-b-1.0 | `-- project-b-1.1 `-- trunk |-- project-a `-- project-b 

Este tipo de layout no tiene un análogo directo en mercurial. Cada proyecto que tiene su propio ciclo de publicación y sus propios numbers de versión debe tener su propio repository.

Algunos repositorys de subversión están estructurados para hacer esto dando a cada proyecto su propio tronco, tags y twigs:

 . |-- project-a | |-- branches | | |-- 1.x | | `-- feature-1 | |-- tags | `-- trunk `-- project-b |-- branches |-- tags | |-- 1.0 | `-- 1.1 `-- trunk 

Puede pensar en cada proyecto como un repository lógico dentro de su repository físico de subversión. Cada proyecto tiene su propio tronco, tags y twigs. Esto también tiene el beneficio de que puede mantener los nombres de las tags y twigs más cortas porque ya sabe a qué proyecto pertenecen.

Este layout también es trivial para express con una herramienta como mercurial. Cada "proyecto" se convierte en un repository mercurial. Las tags y las twigs dentro de ese repository son tags y twigs de ese proyecto.

Como dice Bendin, debe crear múltiples repositorys, uno para cada proyecto independiente como inicio.

Las confirmaciones de Mercurial se hacen a nivel de todo un repository y no se puede get solo un subdirectory. Esto es diferente de Subversion, que le permite realizar confirmaciones consistentes al comprometer solo algunos files, pero luego también le permite extraer solo un subdirectory.

Cuando realizas una publicación, normalmente agregarás una label a tu repository de Mercurial ( hg tag ). Puede decidir libremente si desea mantener un repository de solución de errores para cada versión, o si desea crearlos cuando sea necesario la primera vez. El truco es que

 % hg clone -r 1.0 project-a project-a-1.0.x

se puede usar para crear un repository project-a-1.0.x que solo tiene el historial hasta la label 1.0 . A continuación, puede corregir el error en project-a-1.0.x y empujarlo de nuevo a project-a . Se pueden realizar otras correcciones de errores en el repository de project-a-1.0.x .

Creo que quieres probar la extensión forestal mercurial