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«
.
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?) –
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 –
@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