¿Cuál es la forma correcta de trabajar con (diferentes) repositorys remotos SVN a través de GIT?

El medio ambiente:

  • Un repository SVN cercano llamado svn + ssh: // yourserver / svn / prj
  • Un repository SVN externo llamado svn + ssh: // theirserver / svn / prj
  • Un repository git local que llamó "myrep" que es un clon git-svn del cercano
    • hecho con: git svn clone -R nearbysvn -s svn+ssh://yourserver/svn/prj entonces hay un tronco y algunas twigs (tanto bifurcadas como copydas del tronco r3.
  $ git branch -a
 * maestro
 controles remotos / b1
 controles remotos / b2
 controles remotos / troncales

Aquí vamos.

Los cambios simples realizados en mi maestro (que es una twig de los controles remotos / troncal) se agregan, luego se comprometen, luego se "empujan" al SVN a través de git svn dcommit .

Tan bueno tan lejos. El tree ahora se ve así:

 $ git log --graph --oneline --all
 * 1e6277f cambio 3 en b2
 * 7623755 dos nuevas sucursales
 |  * 7901fad change3 en b1
 |  * e83f135 dos nuevas sucursales
 | /  
 |  * 6fac7ad cambio 3
 |  * 5858495 nuevo file test3
 |  * 4cdf2ed change2
 |  * 511ed7a change1
 | /  
 * d5c68ab init

Conclusión 1:

git svn dcommit envía todos los cambios realizados en mi twig maestra local a los controles remotos / tronco SVN, luego lo vuelve a clasificar El resultado y el tree se ven así:

 Prueba de $ git add

 $ git ci
 [maestro 8a03901] testing modificada a través de git para el tronco SVN
  1 file modificado, 1 inserción (+), 1 eliminación (-)

 $ git svn dcommit
 Comprometerse a svn + ssh: // yourserver / svn / prj / trunk ...
     Prueba M
 Comprometido r9
     Prueba M
 r9 = 542eb78f841fc1a4d12f4a72f68e40e3069f3309 (refs / controles remotos / troncal)
 Sin cambios entre HEAD actual y refs / remotes / trunk
 Restablecer los últimos refs / remotos / trunk

 $ git log --graph --oneline --all
 * 542eb78 testing modificada vía git para el tronco SVN
 * 6fac7ad cambio 3
 * 5858495 nuevo file test3
 * 4cdf2ed change2
 * 511ed7a change1
 |  * 1e6277f cambio 3 en b2
 |  * 7623755 dos nuevas sucursales
 | /  
 |  * 7901fad change3 en b1
 |  * e83f135 dos nuevas sucursales
 | /  
 * d5c68ab init

Pregunta 1:

  • ¿Por qué init es el padre de b1 y b2?
  • ¿Por qué mi maestro es el mismo que el tree "init", no debería ser una "twig" del tree remoto? El estado de fusión sigue "sin fusionar" porque solo se realizó una rebase

Pregunta 2:

cuál es la mejor / la mejor forma de parchar algunos cambios en el control remoto / b1

a mi manera: crea una twig local myb1 con git checkout -b myb1 remotes/b1 luego $ git diff master^..master | patch -p1 $ git diff master^..master | patch -p1 luego agregar, ci, dcommit

Pregunta 3:

¿Cómo puedo get información sobre mis sucursales a qué routes remotas pertenecen / se bifurcan? config no me dice nada al respecto:

  $ git config --get-regexp svn-remote
 svn-remote.nearbysvn.url svn + ssh: // yourserver / svn / prj
 svn-remote.nearbysvn.fetch trunk: refs / remotes / trunk
 svn-remote.nearbysvn.branches branches / : refs / remotes /
 svn-remote.nearbysvn.tags tags / : refs / remotos / tags /

Pregunta 4:

Esto es más complicado: el segundo SVN (externo) ahora es un "duplicado" del primero, con una exception: el externo también puede ser utilizado por otros. Actualmente, todos los cambios realizados en "cerca" deben realizarse nuevamente en el externo (parchear files en una segunda copy de trabajo, y así sucesivamente …

Si este eliminar SVN es ahora un segundo repository SVN remoto, ¿cuál es la mejor práctica para "optimizar" esto con fusiones a través de git?

Sí, hay algunos types geniales que usarán BeyondCompare, etc. (ver Cómo comparar fuente en el repository Git entre fonts en el repository SVN ). Pero esta NO es mi forma favorita de "fusionar"

Propongo que necesito: * twigs locales como myb1, master, master2 * forks / twigs de esto para mi trabajo como master-taskX ( git checkout -b master-taskX ) * entonces podría usar merge para volver mis cambios a master y ¿luego comprometerlos?

Estaré contento de saber de algunos expertos de git-svn pronto;)

Con saludos cordiales, ~ Marcel

Apéndice:

FYI: aquí está el historial inicial de SVN para "cercano":

 -------------------------------------------------- ----------------------
 r8 |  konqi |  2011-01-19 17:48:51 +0100 (Mi, 19 de enero de 2011) |  2 líneas
 Pasos cambiados:
    M / branches / b2 / test3

 cambiar 3 en b2

 -------------------------------------------------- ----------------------
 r7 |  konqi |  2011-01-19 17:48:42 +0100 (Mi, 19 de enero de 2011) |  2 líneas
 Pasos cambiados:
    M / branches / b1 / test3

 change3 en b1

 -------------------------------------------------- ----------------------
 r6 |  konqi |  2011-01-19 17:46:07 +0100 (Mi, 19 de enero de 2011) |  2 líneas
 Pasos cambiados:
    M / trunk / test3

 cambio 3

 -------------------------------------------------- ----------------------
 r5 |  konqi |  2011-01-19 17:36:13 +0100 (Mi, 19 de enero de 2011) |  3 líneas
 Pasos cambiados:
    A / branches / b1 (desde / trunk: 1)
    R / branches / b1 / test (de / trunk / test: 2)
    R / branches / b1 / test2 (de / trunk / test2: 3)
    A / branches / b1 / test3 (de / trunk / test3: 4)
    A / branches / b2 (desde / trunk: 1)
    R / branches / b2 / test (de / trunk / test: 2)
    R / branches / b2 / test2 (desde / trunk / test2: 3)
    A / branches / b2 / test3 (de / trunk / test3: 4)

 dos nuevas twigs


 -------------------------------------------------- ----------------------
 r4 |  konqi |  2011-01-19 17:30:05 +0100 (Mi, 19 de enero de 2011) |  2 líneas
 Pasos cambiados:
    A / trunk / test3

 nuevo file test3

 -------------------------------------------------- ----------------------
 r3 |  konqi |  2011-01-19 17:28:46 +0100 (Mi, 19 de enero de 2011) |  2 líneas
 Pasos cambiados:
    M / trunk / test2

 change2

 -------------------------------------------------- ----------------------
 r2 |  konqi |  2011-01-19 17:28:34 +0100 (Mi, 19 de enero de 2011) |  2 líneas
 Pasos cambiados:
    M / tronco / testing

 cambio1

 -------------------------------------------------- ----------------------
 r1 |  konqi |  2011-01-19 17:28:10 +0100 (Mi, 19 de enero de 2011) |  2 líneas
 Pasos cambiados:
    A / sucursales
    A / tags
    Un tronco
    A / tronco / testing
    A / trunk / test2

 en eso

 -------------------------------------------------- ----------------------

  • ¿Por qué init es el padre de b1 y b2?
    • Debido a que en el historial de svn, init crea la carpeta 'branches', y git-svn lo considera el padre de todas las confirmaciones de twigs. Al final, es solo una convención y no es particularmente importante para ninguna funcionalidad.
  • ¿Por qué mi maestro es el mismo que el tree "init", no debería ser una "twig" del tree remoto?
    • Es una twig del control remoto, pero los commit de git no son parte de las sucursales, así no es como piensa git. Para git, una "twig" es un puntero a una confirmación, que incluye por implicación a todos los padres. Los commits en sí mismos no saben ni les importa de qué twig (s) forman parte.
  • El estado de fusión sigue "sin fusionar" porque solo se realizó una rebase
    • (no tengo idea de lo que estás hablando aquí)

Pregunta 2:

  • cuál es la mejor / la mejor forma de parchar algunos cambios en el control remoto / b1
    • Si no está haciendo una fusión completa, intente con git cherry-pick (vea la ayuda de git cherry-pick); es más o less una manera más fácil y confiable de hacer lo que ya está haciendo

Pregunta 3:

  • ¿Cómo puedo get información sobre mis sucursales a qué routes remotas pertenecen / se bifurcan?
    • Puede consultarlos y ejecutar git svn info, o usar git log y grep para la línea svn en la parte inferior del post de confirmación que enumera la ruta y la rev del origen. El último es la fuente autorizada de git-svn para el origen de los commit de svn.

Pregunta 4:

  • Esto es más complicado: el segundo SVN (externo) ahora es un "duplicado" del primero, con una exception: el externo también puede ser utilizado por otros. Actualmente, todos los cambios realizados en "cerca" deben realizarse nuevamente en el externo (parchear files en una segunda copy de trabajo, y así sucesivamente …

    Si este eliminar SVN es ahora un segundo repository SVN remoto, ¿cuál es la mejor práctica para "optimizar" esto con fusiones a través de git?

    Sí, hay algunos types geniales que usarán BeyondCompare, etc. (ver Cómo comparar fuente en el repository Git entre fonts en el repository SVN). Pero esta NO es mi forma favorita de "fusionar"

    Propongo que necesito: * twigs locales como myb1, master, master2 * forks / twigs de esto para mi trabajo como master-taskX (git checkout -b master-taskX) * entonces podría usar merge para volver mis cambios a master y ¿luego comprometerlos?

    • Tendría dos repositorys de git en la misma máquina, uno (llamémoslos A y B) configurados para rastrear cada svn repo. Haz tu desarrollo en A, configurado para rastrear el repository cercano. Haz que B registre A como un git "remoto" regular (git remote add / path / to / repo / A) después de git svn clone. Una vez que tenga sus confirmaciones lists para comprometerse en A, use git fetch -f en B para llevarlas allí. Entonces git svn dcommit en A; en B use algo como git checkout -b temp A/master; git rebase --onto trunk HEAD^; git svn dcommit; git checkout master; git branch -D temp git checkout -b temp A/master; git rebase --onto trunk HEAD^; git svn dcommit; git checkout master; git branch -D temp git checkout -b temp A/master; git rebase --onto trunk HEAD^; git svn dcommit; git checkout master; git branch -D temp para confirmar los cambios al repository B. Para realizar múltiples recargas, deberás ajustar el número de quilates en el command rebase.

Tenga en count, en general, que en mi experiencia, git merge no funciona bien con git-svn, por lo que probablemente quiera seguir técnicas como la anterior, que no crean confirmaciones de dos padres en el historial de git.

Haría 2 repositorys git separados para los 2 repositorys svn. Luego, coordine los cambios a través de rebase, etc. en uno de los repositorys de Git.