Problema de flujo de trabajo Mercurial a Mercurial a Subversion

Question

Estamos migrando de Subversion a Mercurial. Para facilitar la migración, estamos creando un repositorio intermedio de Mercurial que es un clon de nuestro repositorio de Subversion. Todos los desarrolladores comenzarán a cambiar al repositorio de Mercurial, y periódicamente haremos cambios desde el repositorio de Mercurial intermedio al repositorio de Subversion existente. Después de un período de tiempo, simplemente obsoletos el repositorio de Subversion y el repositorio intermedio de Mercurial se convertirá en el nuevo sistema de registro.

Dev 1 Local --+--> Mercurial --+--> Subversion 
Dev 2 Local --+    + 
Dev 3 Local --+    + 
Dev 4 -------------------------+ 

He estado probando esto, pero yo sigo corriendo en un problema cuando empujo cambios de mi repositorio local, al repositorio Mercurial intermedia, y luego hacia arriba en nuestro repositorio Subversion.

alt text http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/01.png

en mi máquina local, que tienen un conjunto de cambios que está comprometido y listo para ser empujado a nuestro repositorio Mercurial intermedia. Aquí se puede ver que es la revisión # 2263 de almohadilla 625 ...

alt text http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/02.png

empujo solamente este conjunto de cambios al repositorio remoto.

alt text http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/03.png

Hasta ahora, todo se ve bien. El conjunto de cambios ha sido empujado.

hg update 
1 files updated, 0 files merged, 0 files removed, 0 files unresolved 

Paso ahora al repositorio remoto y actualizo el directorio de trabajo.

hg push 
pushing to svn://... 
searching for changes 
[r3834] bmurphy: database namespace 
pulled 1 revisions 
saving bundle to /srv/hg/repository/.hg/strip-backup/62539f8df3b2-temp 
adding branch 
adding changesets 
adding manifests 
adding file changes 
added 1 changesets with 1 changes to 1 files 
rebase completed 

A continuación, presiono el cambio a Subversion, funciona muy bien. En este punto, el cambio está en el repositorio de Subversion y devuelvo la atención a mi cliente local.

alt text http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/04.png

Saco cambios en mi máquina local. ¿Huh? Ahora tengo dos conjuntos de cambios. Mi conjunto de cambios original aparece ahora como una rama local.

alt text http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/05.png

El otro conjunto de cambios tiene un nuevo número de revisión de 2264, y un nuevo hash de 10C1 ...

alt text http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/06.png

De todos modos, puedo actualizar mi repo local para la nueva revisión.

alt text http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/07.png

Ahora estoy cambió.

alt text http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/08.png

Así, finalmente haga clic en "determinar y marcar conjuntos de cambios salientes" y como se puede ver Mercurial todavía quiere empujar a mis conjuntos de cambios anteriores a pesar de que ya han sido empujados.

Claramente, estoy haciendo algo mal.

Tampoco puedo combinar las dos revisiones.Si fusiono las dos revisiones en mi máquina local, termino con una confirmación de "fusión". Cuando presiono esa fusión me comprometo con el repositorio intermedio de Mercurial, ya no puedo enviar cambios a nuestro repositorio de Subversion. Termino con el siguiente problema:

hg update 
0 files updated, 0 files merged, 0 files removed, 0 files unresolved 

hg push 
pushing to svn://... 
searching for changes 
abort: Sorry, can't find svn parent of a merge revision. 

y tengo que deshacer la fusión para volver a un estado de trabajo.

¿Qué me estoy perdiendo?

Answer 1

No está haciendo nada malo, de hecho, en su situación, el comportamiento que está viendo es el resultado esperado (aunque algo confuso para un nuevo usuario de Mercurial).

hgsubversion es realmente bueno para dos cosas:

1. utilizando Mercurial como un cliente de Subversion, sin intercambiar cambios fuera del SVN
2. Conversión de repositorios de Subversion en Mercurial

Usted está tratando usarlo como una entrada más generalizada, que es un problema mucho más difícil. Subversion tiene una visión muy rígida del mundo, y tenemos que trabajar dentro de eso. La verdad del asunto es que el hash de revisión solo se puede ver como definitivo cuando se usa hgsubversion una vez que la revisión se ha retirado de Subversion. Por lo tanto, si sus desarrolladores alguna vez comparten conjuntos de cambios entre repositorios de Mercurial directamente, sin Subversion como intermediario, esto ocurrirá.

La rebase es automática y no opcional por una razón muy fundamental: Subversion realiza esa rebase cuando empuja. Si tenía cambios no activados cuando presionó, Subversion hizo esa rebase por usted, y si tiene éxito (con un algoritmo de rebase básico estúpidamente simple) acepta la confirmación sin indicación de que se produjo una rebase. Estamos arreglando dos modelos diferentes.

Recomendaría trasladar a todos a Mercurial de inmediato, un enfoque híbrido como este solo hará que usar Mercurial sea más difícil a corto plazo de lo que debería ser, y podría confundir a los usuarios nuevos en DVCS.

Answer 2

En primer lugar, déjame decirte qué placer fue leer una pregunta tan detallada. :)

El problema está sucediendo cuando haces el hg push al svn repo desde el control remoto. He aquí que la producción de su ejemplo:

hg push 
pushing to svn://... 
searching for changes 
[r3834] bmurphy: database namespace 
pulled 1 revisions 
saving bundle to /srv/hg/repository/.hg/strip-backup/62539f8df3b2-temp 
adding branch 
adding changesets 
adding manifests 
adding file changes 
added 1 changesets with 1 changes to 1 files 
rebase completed 

No soy un usuario hg-subversión, pero que la producción dice que en el proceso de hacer el empuje que ha solicitado, que está tirando de los cambios desde el repositorio SVN, la búsqueda de una nueva revisión y luego hacer un rebase de su conjunto de cambios 10c1 después de (descendiente de) la revisión recién extraída. El rebase command toma los historiales de bifurcación y los convierte en historias lineales, pero al hacerlo cambia los padres de los conjuntos de cambios, lo que cambia sus valores hash, que se parece a lo que le sucede a usted.

nuevo, no es un usuario hg-subversión, por lo que no puede decir si ese tirón/rebase se supone siempre a suceder y cómo eso se supone que funciona, pero la página hgsubversion wiki dice:

Usted puede usar los comandos habituales de Mercurial para trabajar con este repositorio. Si usted tiene una serie de confirmaciones en una rama determinada , y desea moverlos a la punta de esa rama, utiliza el comando hg rebase --svn mientras que en la punta de su trabajo, y esos conjuntos de cambios se se volverá a configurar automáticamente en la parte superior del nuevo trabajo de subida.

que lo hace sonar no normalmente automático.

No pude distinguir por completo de su introducción, ¿todavía se están creando nuevos conjuntos de cambios en svn, o están creados solo en mercurial?

Si solo se crean en mercurial, una solución alternativa sería configurar un repositorio svn-gateway en el sistema remoto, y hacer el push desde allí, y nunca volver a sacar de ese repo en mercurial. Luego, los conjuntos de cambios en ese repos podrían tener diferentes hashids debido a la rebase, pero no volverían al repo remoto principal y a los sistemas del usuario final.

La mejor solución es averiguar por qué "hg push svn: // .. está rebaseando todos los conjuntos de cambios salientes". Responda eso y el comportamiento se detendrá.

Answer 3

Estamos utilizando el comando injerto ahora para hacer algo similar a esto. Efectivamente recreamos cada conjunto de cambios antes de empujarlo para evitar tener que empujar conjuntos de cambios de fusión.

Nuestro objetivo es contribuir limpiamente a un proyecto que utiliza la subversión.

• Cree una rama de subversión para todos sus cambios. Obténgalo en Mercurial.
  $ cd [svn-checkout] ; svn cp trunk branches/hg-bridge
  $ cd [hgsubversion bridge] ; hg pull ; hg update hg-bridge

• Compruebe tu repositorio local para nuevos cambios
  $ hg in [repo] # shows <rev> IDs you can use later

• Tire de los cambios que desea entrar en svn de un acuerdo de recompra locales
  $ hg pull [repo]

• Graft todos los cambios que desee contribuir:
  $ hg graft [rev] [rev] # rev could be 645 or b7a92bbb0e0b. Best use the second>.
  Debe especificar cada rev de manera individual,
  , pero puede injertar varias revoluciones en un solo comando.

• Comprobar lo que empujaría:
  $ hg outgoing

• empujar los cambios:
  $ hg push
  Este fuerza muestran algunas revisiones tirados sin relación
  y deben mostrar sus nuevas revisiones como extraído,
  junto con las rutas a los paquetes de copia de seguridad (que no debería necesitar). (también se puede usar el comentario ajo la GPLv2 o posterior)