2010-04-02 13 views
7

¿Es posible fusionar un rango de revisiones de una rama a otra en Mercurial?fusionando revisiones seleccionadas de una rama en otra en Mercurial

p. Ej.

|r1 
|r2 
|r3 
|\___ 
| | r5 
| | r6 
| | r7 
| | ... 
| | r40 
|r41 

Si quiero fusionar las revisiones 6 & 7, pero no 5, en la rama principal - es esto posible?

una fusión de este tipo puede ser trivial, por ejemplo, si R5 archivos que no sean modificados de 6 & 7 (y por lo tanto sus cambios, si no es necesario, pueden con seguridad ser ignorados)

¿Qué hay de revisión seleccionada múltiples modificado va de la rama A a la rama B? p.ej. fusionar 4-7, 20-25 y 30-34?

(esto no es un caso real, sólo una ilustración. Estoy tratando de entender si hg tiene esta característica de combinación de la revisión de gama que sé que tiene SVN)

Respuesta

7

La respuesta simple es sin.

Esto es contrario al espíritu de Mercurial.

Su gráfico implica que 6 depende de 5 así que cualquier cosa que tira 6 debe tirar de 5 también de lo contrario no tiene sentido.

Me parece que aquí se equivocó con Mercurial. Si su árbol de cambios es lineal, generalmente es una señal de que está usando Mercurial como si usara CVS o SVN.

Su árbol de cambio debería parecerse más a:

4 
/\ 
/| |\ 
/| | \ 
5 7 23 \ 
| | | 25 
6 8 24 | 
     26 

Y entonces usted podría tirar de la rama ya sea a partir de las 5 o el que a partir de las 23.

Ahora, el error es humano, por lo que hay una "instalación" llamada exportar, que le permite crear un archivo diff simple a partir de un conjunto de cambios.

En su caso específico, lo haría así:

  • clon del repositorio hasta r4
  • crear un diff de r6 y uno de r7 (exportación)
  • se aplican tanto (en orden) en el nuevo clon (importación)
  • ejecutar pruebas unitarias hasta que pasen
  • cometer
  • tirón en r41
  • fusión
  • ejecutar pruebas unitarias hasta que pasen
  • cometer

Si lo desea, también se puede ir a la carretera de extensión. Hay varias extensiones útiles para manipular los conjuntos de cambios. Un conjunto de muestras:

Aquí se podría, por ejemplo, clonar el repositorio (importante, siempre analizan estos en los clones, por si acaso) y luego colapsan los rangos de su interés in. Luego puede exportarlos/importarlos.

+0

No es cierto que r6 deba depender de r5 de manera significativa. Por ejemplo, podría ser que r5 cambie solo un archivo que otras revisiones no tocan, por lo que no hay ningún problema en ignorar esa revisión en particular (desde un punto de vista centrado en los datos). Por favor, no asumas que estoy usando hg de esta manera, solo estoy tratando de entender sus capacidades. –

+0

Además, no entendí exactamente lo que quiere decir por la forma en que debería verse el árbol. La ilustración de su árbol muestra múltiples ramas con pocas revisiones. ¿Es ese el espíritu de hg, solo para tener ramas cortas? Porque a veces simplemente necesitas una rama separada para hacer mucho trabajo que no va en el maletero. Si mantiene muchas versiones históricas, no es factible tener un repositorio por versión, por lo que las sucursales son la única solución razonable. Entonces, ¿cómo sugieres mantener estas ramas cortas, y por qué sería mejor que tener múltiples ramas divergentes cuando sea necesario? –

+0

r6 depende de r5 porque usted dijo que sí cuando hizo el padre de r5 r6. Si desea evitar eso, y no están realmente relacionados, puede "actualizar" a un padre diferente antes de hacer el cambio 6. Si antes de hacer r6 había hecho 'hg update r4', entonces el padre de r6 sería r4, y usted podría moverlo a cualquier rama de desarrollo que ya tuviera r4. En el sentido más amplio al hacer un cambio pregúntese "¿cuál es el primer punto en la historia que podría haber hecho esto?" Y luego "hg update" hasta ese punto. Luego tiene un conjunto de cambios que se puede fusionar fácilmente en cualquier lugar que tenga sentido. –

Cuestiones relacionadas