2011-03-17 5 views
7

Estoy trabajando en un equipo que usa SVN principalmente, mientras que prefiero usar Mercurial cuando sea posible. Configuré un clon hg del repositorio SVN usando hgsubversion, y varios pull/commit/empujes básicos parecían funcionar bien.Pasos necesarios para permitir que hgsubversion Clone SVN retroceda

Ahora, después de 2 semanas de desarrollo local (durante las cuales me he fusionado en cambios desde un repositorio hg externo, y me he fusionado varias veces desde el repositorio SVN), he intentado insertar el repositorio SVN, pero falló con este mensaje:

abortar: Lo sentimos, no se puede encontrar el padre svn de una revisión de fusión.

He encontrado otros usuarios que enfrentan el mismo problema, con instrucciones sobre cómo evitar este problema en el futuro, pero no he encontrado nada que parezca abordar la condensación de múltiples compromisos paralelos para limpiar una existente repositorio de hgsubversion.

¿Cuál es la mejor forma en que puedo solucionar los problemas sin perder mis propios compromisos? (¿Con instrucciones paso a paso?)

Respuesta

9

No puede insertar hg merges en un repositorio de subversión, ya que SVN no puede entenderlas. Necesita volver a establecer la base de sus cambios sobre la última confirmación de SVN.

Editar Pasos para aplanar la historia:

Advertencia, estar preparado para hacer tener un montón de conflictos de fusión

Se necesita el MQ y rebase extensión activa

El primer paso es crear un repositorio de respaldo, ya que lo necesitará como referencia para los próximos conflictos de fusión (se esperan muchos de ellos).

Digamos que su gráfica se parece a esto:

C1--C2--C3------M1--C5--C6--C7---M2-- 
    \   /\   /
    \--B1--B2--/ \--B3--B4-B5-/ 

A continuación, el segundo paso es cambiar la base B1 + B2 en la parte superior de C3: hg rebase -b B2 -d C3

-b utilizar la base común de ambas ramas como el inicio de la rama para rebase, por lo que Mercurial encuentra que B1 es la primera desviación comprometida y usa esto aun cuando digas B2 a rebase. -d especifica el destino de la rama rebasada.

Cuando se encuentre con conflictos de fusión, asegúrese de que el resultado de B2 '= M1, de lo contrario, obtendrá muchos conflictos en las siguientes revisiones.

Después Merge M1 se ha ido y el gráfico se ve así:

C1--C2--C3--B1'--B2'--C5'--C6'--C7'---M2'-- 
        \    /
        \--B3'--B4'-B5'-/ 

y ahora hacer lo mismo para la segunda fusión: hg rebase -b B3' -d C7', lo que hace que su cesión temporal de esta manera:

C1--C2--C3--B1'--B2'--C5'--C6'--C7'--B3''--B4''--B5'' 

Repita hasta que tenga un historial de versiones completamente lineal.

Después de haber aplanado el historial que necesita para reordenar sus confirmaciones además de las confirmaciones de svn. Digamos que su repo ahora se ve así (S = subversión cometió, C = local cometió):

S1--S2--S3--C1--C2--S4--S5--C3-C4--C5--C6--C7--S6--S7 

Ahora se importa todo, desde (incluido) C1 en una cola de mercurio (hg qimport -rC1:). Para ver todos los parches creados, use hg qseries.

Luego, desinstala todos los parches (hg qgoto C1.diff [this is the first one in qseries], seguido de hg qpop). Luego eliminas los de subversión (hg qdelete S4.diff S5.diff S6.diff S7.diff).

Ahora es el momento de volver a traer el SVN se compromete (hg pull »svn-remote«). A continuación, vuelva a aplicar todos los parches locales, uno por uno con hg qpush, y solucione todos los conflictos de fusión que se están produciendo. Cuando haya terminado con un conflicto, puede mover el parche actual en una confirmación mercurial con hg qfinish -a y enviar su estado actual con hg push »svn-remote«.

+0

Bien, lo he deducido de otras publicaciones, después de los hechos. Entonces, ¿cómo puedo arreglar lo que ya se ha hecho? (¿Cuál fue mi pregunta original, de hecho?) –

+0

Ahhh, perfecto. Intenté averiguar cómo hacer que esto sucediera utilizando rebase y colapso, pero no tenía los comandos correctos. Este es un gran tutorial, gracias. Como tenía que enviar mi código a SVN más temprano que tarde, seguí y creé una diferencia SVN de mi repo cambiado frente a SVN predeterminado, y lo apliqué como una única confirmación. La historia se ha perdido para SVN, pero gracias a su publicación, ahora sé cómo reparar esto en el futuro si vuelve a suceder. Cheers –

+1

@Jon Contra las mejores prácticas de hg normales, es mejor nunca fusionar el historial divergente en un repositorio conectado SVN. Cuando vuelves a calcular tu trabajo después de una extracción de un repositorio svn, estás en un estado potencial de empuje después. – Rudi

Cuestiones relacionadas