2011-05-05 9 views
6

Aquí está la situación: el desarrollador Foo creó un repositorio hg de nuestro repositorio svn. El repo hg de Foo era solo un clon superficial del tronco en svn (sin ramas svn, etiquetas, etc. y la historia estaba incompleta [alrededor de 100 conjuntos de cambios]). Developer Bar hizo lo mismo, pero clonó todo el repositorio svn incluyendo todo el historial, las ramas, las etiquetas, etc. Tanto Foo como Bar han hecho un desarrollo detallado en sus repositorios.Reparar en Mercurial: ¿cómo uno trae dos clones de svn independientes juntos?

Hay un antecesor SVN común en ambos repositorios, pero cada repositorio hg tiene un número de versión diferente para él. Me gustaría reparar los cambios de Foo del ancestro común en el repositorio de Bar. He aquí un diagrama de lo que estoy buscando:

cesión temporal de Foo:

C'-D'-E-F---G 
     \ /
     H-I 

de barra de recompra:

...A-B-C-D-J-K---L 
      \ /
      M-N 

C, C 'y D, D' tienen el mismo contenido, pero números de versión diferentes & comentarios.

El objetivo:

...A-B-C-D--E-F---G 
      \ \ /
      \ H-I 
      \ 
      J-K---L 
       \ /
       M-N 

me he quedado sin ideas sobre cómo hacer que esto suceda. Intenté convertir --splicemap splice.map [archivo splice.map contenía E D] (no hice nada). Clone -f logró obtener todo en un repositorio, pero parecen ser árboles independientes. Después -f clon, he intentado rebasar --source E --dest D --detach, pero acaba de estrellarse :(

ideas?

Soy consciente de alterar la historia invalidará el clon de cualquiera de los repositorios , esto no es un problema en este caso. Todos los usuarios serán re-clonación a partir del resultado de este esfuerzo.

Respuesta

2

¡RESUELTO!

Una cosa que no noté inicialmente fue que mi presunto antepasado común no era exactamente el mismo después de todo. Durante la conversión de svn-> hg del repositorio de Foo, las cadenas de $ ID $ se expandieron, pero no estaban en la creación del repositorio de Bar. El paso 1 a continuación fue una solución simple para crear un antepasado común REAL.

Los siguientes pasos permiten que logre mi objetivo:

1- Asegúrese de que el ancestro común presunta (D y D ') son en realidad idénticos. De lo contrario, cree un nuevo punto de empalme para ellos (S) en el repositorio de Bar. S debería coincidir exactamente con el contenido de D 'en mi ejemplo.

 
    ...A-B-C-D--J-K---L 
       \ \ /
       S M-N 

2- Recorte la historia de la cesión temporal de Foo para eliminar la historia duplicado, incluyendo D', con

 
    hg convert --splicemap TrimSplicemap Foo FooTrimmed 

contenidos TrimSplicemap: (donde E es el hash total de E)

 
    E 0000000000000000000000000000000000000000 

3- franja uso Hg para eliminar la, historia redundante desconectado

 
    cd FooTrimmed 
    hg strip C' 

4- Use hg convertir de nuevo para empalmar repo despojado de Foo en repo de bar durante la confirmación 'S'

 
    cd ../Bar 
    hg convert --splicemap FooBarSplicemap ../FooTrimmed . 

contenidos FooBarSplicemap: (donde E' es el nuevo hash para E en el FooTrimmed, y S es el hash de S)

 
    E' S 

Eso debería hacerlo! : D

+0

Cuando intento esto, no lo hace diciendo "la revisión del mapa de empalme no se está convirtiendo, ignorando" – simplename

1

Usted puede poder lograr esto usando Mercurial Queues.

  1. importación cada conjunto de cambios de recompra Foo en una cola de parches.
  2. Ir al Bar repo.
  3. Actualización Bar al conjunto de cambios que es el antecesor común.
  4. Importe la cola de parches en Bar.
  5. Aplicar la cola de parches.

Esto cambiaría las cometer ID de todos los Foo parches, pero todavía permitirá mantener toda la historia y que combine repositorio de su dev juntos.

+1

El problema con eso es que los conjuntos de cambios de fusión no funcionan bien con MQ, por lo que G y L en su ejemplo no se aplicarían con sus dos padres. El trasplante tiene el mismo problema. –

1

Hablamos de esto hoy en el IRC y mi consejo fue simplemente juntar ambos en el mismo repositorio y dejar que tenga dos raíces. Las cabezas serán exactamente como quieras y el resto realmente no importa.

Si usted simplemente no puede soportar que (usted está imaginando la gente utiliza la historia/culpar más de lo que realmente lo hacen) entonces creo que su splicemap debe tener:

E D 

en en el puesto que usted está tratando para obtener el padre de E para ser D (no D ')

+0

Sí, E D es correcto, edité el diagrama ayer y no actualicé el texto. Gracias por señalar eso. Tener dos árboles independientes en el repositorio es mi posición de recuperación, y tener esa solución lista si es necesario. Creo que 'culpar' funcionaría bien con los dos árboles ... si esa fuera nuestra única necesidad de la historia, entonces estaríamos en buena forma. – mattjackets

+0

Suena bien. Recuerde que siempre puede mantener SVN alrededor de solo lectura también. Ha cumplido con sus requisitos de historia durante años, por lo que dejarlo disponible probablemente los maneje hasta el punto de la transición. Eventualmente, la gente dejará de consultarlo, pero no hay costo en mantenerlo para el trabajo arqueológico. –

+0

Muy cierto, gracias por mantener las cosas en perspectiva para mí. Es fácil quedar envuelto en el desafío. – mattjackets

Cuestiones relacionadas