"Hg a Hg (Gateway) a SVN" en comparación con "Git a Git (Gateway) a SVN"

La pregunta es similar a esto (sin respuesta) y a este (el mismo problema no involucra a Git).

El objective es hacer que Hg una interfaz para SVN durante un período de time antes de realizar una transición completa a Hg.

La configuration probablemente debería verse como la que se muestra a continuación (igual que en las preguntas mencionadas anteriormente), sin embargo, no estoy seguro de la topología exacta de los repositorys Hg intermedios.

 Dev1 Hg --> Hg <--> SVN Dev2 Hg -/ 

Sé que la configuration anterior funciona con git y git-svn como se describe en este comentario :

 Dev1 Git --> Git (bare) <--> Git (bridge) <--> SVN Dev2 Git -/ 

Preparar:

  1. O bien git svn init , o git svn clone el repository SVN. Esto se convierte en el "Puente Git / SVN".

  2. Repare cualquiera de las twigs, tags, etc … aquí. Los svn/* refs se consideran controles remotos, por lo que si desea rastrear sucursales, verifique estos controles remotos y cree las sucursales locales apropiadas. Además, verifique las tags y cree tags reales. DEBE crear sucursales locales para cualquier twig SVN que desee sincronizar entre Git y SVN.

  3. Ahora, cree un nuevo repository desnudo ( git init ) en alguna parte, y desde el puente, empuje todas las twigs al repository desnudo ( git push –tags ).

  4. Todos los usuarios de Git ahora clonan este repository simple. El puente solo lo mantendrán una (o algunas) personas que entiendan cómo sincronizar Git y SVN.

Para actualizar el tronco SVN con cambios en el maestro, y viceversa, desde el puente:

  1. git svn fetch (get nuevos cambios SVN)

  2. git checkout master

  3. git pull master (get cambios de Git desde el repository desnudo)

  4. git checkout svn/trunk (checkout cabeza separada)

  5. git merge –no-ff –log master (merge changes from master). –no-ff asegura una confirmación real, –log copy los posts de logging individuales de cada confirmación en el maestro ( –log es opcional). git commit -amend se puede ejecutar si desea editar el post de confirmación.

  6. git svn dcommit (Esto hace que su fusión se comprometa con SVN. Tenga en count que la confirmación se realizó en un encabezado separado, y ya no está accesible). Todo su trabajo en master (desde la base de combinación de master y svn/trunk ) se compromete como un único cambio, y ahora está disponible para usuarios de SVN.

  7. git checkout master

  8. git merge svn/trunk (Obtiene las nuevas actualizaciones de SVN – con el post de confirmación modificado – y se fusiona con el maestro)

  9. git push barerepo (hace que los cambios SVN estén disponibles para los usuarios de Git)

Lo que no sé es si es posible replicar de alguna manera lo anterior en Hg. Como lo veo (soy un usuario intermedio de Git y sé básico sobre cómo trabajar con Hg), los obstáculos en Hg son:

  • no hay twigs de rastreo remoto (¿esto es posible con marcadores ? ¿repositorys clónicos separados?)
  • imposibles de presionar merge commits a través de hgsubversion (paso n. ° 6 en la list anterior. ¿Qué impide que hgsubversion haga lo que svn dcommit hace?)

¿Es posible hacer que la pasarela Hg-SVN funcione de la misma manera que funciona la pasarela Git-SVN? Si no, ¿por qué?

La versión corta es la siguiente: nadie me ha convencido aún del comportamiento razonablemente esperado de empujar una fusión a Subversion, y hay algunas modificaciones leves a hgsubversion aconsejables para hacer que el empuje resulte en fusiones en lugar de revisiones reestadificadas. Nada de eso debería ser demasiado difícil, simplemente lleva a alguien motivado a hacer la implementación. Si tiene curiosidad, este hilo tiene una request similar en la que respondí con una discusión bastante profunda sobre el enfoque básico que he pensado con un par de otros.

Intereting Posts