svn - Problema del flujo de trabajo de Mercurial a Mercurial a Subversion

hgsubversion (3)

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 sigo teniendo un problema cuando envío cambios desde mi repositorio local, al repositorio intermedio de Mercurial y luego a nuestro repositorio de Subversion.

texto alternativo http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/01.png

En mi máquina local, tengo un conjunto de cambios que está comprometido y listo para ser enviado a nuestro repositorio intermedio de Mercurial. Aquí puedes ver que es la revisión # 2263 con hash 625 ...

texto alternativo http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/02.png

Solo envío este conjunto de cambios al repositorio remoto.

texto alternativo 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

Ahora cambio 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

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

texto alternativo http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/04.png

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

texto alternativo http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/05.png

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

texto alternativo http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/06.png

De todos modos, actualizo mi repositorio local a la nueva revisión.

texto alternativo http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/07.png

Ahora estoy cambiado.

texto alternativo http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/08.png

Por lo tanto, finalmente hago clic en "determinar y marcar los conjuntos de cambios salientes" y, como pueden ver, Mercurial todavía quiere sacar mis conjuntos de cambios anteriores, aunque ya los hayan empujado.

Claramente, estoy haciendo algo mal.

Tampoco puedo fusionar 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?

Estamos usando el comando de 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.

Crea una rama de subversión para todos tus cambios. Obténgalo en Mercurial.
$ cd [svn-checkout] ; svn cp trunk branches/hg-bridge cd [svn-checkout] ; svn cp trunk branches/hg-bridge
$ cd [hgsubversion bridge] ; hg pull ; hg update hg-bridge cd [hgsubversion bridge] ; hg pull ; hg update hg-bridge
Verifique su repositorio local para nuevos cambios
$ hg in [repo] # shows <rev> IDs you can use later
Tire de los cambios que desea ingresar a svn desde un repositorio local
$ hg pull [repo]
Graba todos los cambios que quieras contribuir:
$ hg graft [rev] [rev] # rev could be 645 or b7a92bbb0e0b. Best use the second>. hg graft [rev] [rev] # rev could be 645 or b7a92bbb0e0b. Best use the second>.
Debe especificar cada rev de forma individual,
pero puedes injertar varias revoluciones en un solo comando.
Verifica lo que impulsarías:
$ hg outgoing
Presione los cambios:
$ hg push
Esto podría mostrar algunas revisiones extraídas no relacionadas
y debe mostrar sus nuevas revisiones como extraídas,
junto con las rutas para hacer copias de seguridad de los paquetes (que no debería necesitar). (El comentario también se puede usar en la GPLv2 o posterior)

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

hgsubversion es realmente bueno para dos cosas:

usando Mercurial como cliente para Subversion, sin intercambiar cambios fuera de svn
Conversión de repositorios de Subversion a Mercurial

Está tratando de usarlo como una puerta de 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 al presionar. 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.

Recomiendo trasladar a todo el mundo 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.

Primero, permítanme decir qué placer fue leer una pregunta tan detallada. :)

El problema está sucediendo cuando haces el hg push al svn repo desde el control remoto. Aquí está la salida de tu ejemplo:

No soy un usuario de subversión hg, pero esa salida dice que en el proceso de hacer la inserción solicitada, está sacando los cambios del repositorio svn, buscando una nueva revisión y luego haciendo una rebase de su conjunto de cambios 10c1 después (descendiente) de) la nueva revisión extraída. El comando rebase toma los historiales de bifurcación y los convierte en historiales lineales, pero al hacerlo, cambia los padres de los conjuntos de cambios, lo que cambia sus hash, que se parece a lo que le está sucediendo.

De nuevo, no es un usuario de subversión-hg, así que no puedo decir si se supone que siempre se producirá ese pull / rebase y cómo se supone que funciona, pero la página wiki de hgsubversion dice:

Puede usar los comandos habituales de Mercurial para trabajar con este repositorio. Si tiene una serie de confirmaciones en una sucursal determinada y desea moverlas a la punta de esa sucursal, use el comando hg rebase --svn mientras esté en la punta de su trabajo, y esos conjuntos de cambios se volverán a establecer automáticamente en la parte superior de el nuevo trabajo upstream.

lo que hace que suene 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 se crearon solo en mercurial?

Si solo se crean en mercurial, entonces una solución alternativa sería establecer un repositorio svn-gateway en el sistema remoto, y hacer el push desde allí, y nunca sacar de ese repo nuevamente 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.

Sin embargo, la solución más importante es averiguar por qué "hg push svn: // .. está rebaseando todos los conjuntos de cambios de salida". Responda eso y el comportamiento se detendrá.