Mercurial con múltiples proyectos
Tengo un par de proyectos con diferentes ciclos de publicación en mi repositorio SVN. Las versiones se crean utilizando la estructura de etiquetas clásicas en SVN. Cuando hay errores que corregir en las versiones, se crea una rama a partir de una etiqueta, el error se corrige y luego se fusiona desde allí en el tronco.
Ahora, por múltiples razones, quiero cambiar de SVN a mercurial con un sitio central de inserción.
Pregunta: ¿Cuál es la mejor manera en mercurial de organizar múltiples proyectos que comparten poco código entre ellos? ¿Debería crear varios sitios push, uno para cada proyecto?
Por favor incluya en la respuesta una descripción sobre cómo recrear mi release-tag, bugfix branch, ... con su versión preferida del diseño del repositorio.
Editar: Me gustaría instalar la menor cantidad de extensiones posible.
Edit2:
Dado este diseño 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 múltiples repositorios push hg
project_a-trunk
project_a-1.x
project_a-feature-1
project_b-trunk
Para el rama. Las etiquetas se pliegan en la rama correspondiente.
O prefieres ir con dos repositorios push en este ejemplo
project_a
project_b
Con ramas nombradas y por lo tanto múltiples cabezas dentro de un repo.
La ventaja que veo con los repositorios de múltiples cabezas es que no tengo que ir a buscar una etiqueta en varios repositorios. La desventaja que veo es que el libro de hg parece desalentar múltiples repositorios de cabeza. ¿Qué harías?
3 answers
Algunos repositorios de subversion agruparán cosas lógicamente no relacionadas (es decir, proyectos con diferentes números de versión y ciclos de publicación) bajo 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 diseño no tiene analógico directo en mercurial. Cada proyecto que tiene su propio ciclo de lanzamiento y sus propios números de versión debe tener su propio repositorio.
Algunos repositorios de subversion están estructurados para hacer esto dando a cada proyecto su propio tronco, etiquetas y ramas:
.
|-- project-a
| |-- branches
| | |-- 1.x
| | `-- feature-1
| |-- tags
| `-- trunk
`-- project-b
|-- branches
|-- tags
| |-- 1.0
| `-- 1.1
`-- trunk
Puedes pensar en cada uno proyecte como un repositorio lógico dentro de su repositorio físico de subversion. Cada proyecto tiene su propio tronco, etiquetas y ramas. Esto también tiene la ventaja de que puede mantener los nombres de las etiquetas y ramas más cortos porque ya sabe a qué proyecto pertenecen.
Este diseño también es trivial de expresar con una herramienta como mercurial. Cada "proyecto" se convierte en un repositorio mercurial. Etiquetas y ramas dentro de ese repositorio son las etiquetas y ramas de ese proyecto.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-05-30 10:59:57
Como dice bendin, debes crear múltiples repositorios, uno para cada proyecto independiente como inicio.
Las confirmaciones de Mercurial se hacen a nivel de todo el repositorio y no se puede obtener solo un subdirectorio. Esto es diferente a Subversion que le permite hacer confirmaciones consistentes al confirmar solo algunos archivos, pero también le permite revisar solo un subdirectorio.
Cuando realice una versión, normalmente agregará una etiqueta a su repositorio Mercurial (hg tag). Puede decidir libremente si desea mantener un repositorio de correcció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 repositorio project-a-1.0.x que solo tiene el historial hasta la etiqueta 1.0. A continuación, puede corregir el error en project-a-1.0.x y empujarlo de nuevo a project-a. Se pueden hacer más correcciones de errores en el repositorio project-a-1.0.x.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-05-30 15:19:42
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-05-30 10:49:48