modelo - ¿Pueden los diferentes clones de git-svn del mismo repositorio svn esperar poder compartir los cambios y luego git svn dcommit?

modelo git

Question

He leído mucho sobre "ir de svn a git" y otros artículos de "git-svn workflow" en la web, y aún creo que a menudo se ocupan de situaciones demasiado simples. A menudo se dirigen a tipos que solo quieren usar git y hack localmente, sin usar todo el poder de git, como pull, fetch, merge y similares entre varios desarrolladores que todos habrían clonado el repositorio svn con git-svn, luego todavía espero poder enviar sus cambios en cualquier momento al repositorio de svn (oficial), y volver a trabajar en git y compartir sus cosas, etc.

Cada vez que estos artículos admiten que no se puede hacer todo lo que se hace en puro git, las consecuencias y posibles complicaciones nunca se explican con claridad (¿o tal vez soy solo yo?). Incluso la página de manual de git-svn menciona advertencias, pero no realmente de una manera extensa.

De acuerdo con lo que he leído, creo que podría haber problemas cuando git-svn se utiliza de esa manera específica, que describiré a continuación. ¿Alguien puede decirme si estoy en lo cierto acerca de esto?

Aquí está la forma "deseada" de hacer las cosas:

1. Tenemos un proyecto en un repositorio svn
2. Desarrollador A git-svn-clone es el svn repo. Él comienza a piratear cosas localmente
3. El desarrollador B git-svn-clone es el mismo svn repo. Él comienza a hackear cosas por sí mismo.
4. Después de hacer eso por algún tiempo, posiblemente agregando desarrolladores C / D / ..., y teniendo otros desarrolladores que hacen commit svn "estándar" al repositorio original, los usuarios de git querrían compartir su código y hacer todo tipo de git magic .
5. Cualquiera de esos usuarios de git quisiera poder impulsar los cambios fusionados ahora a svn (dcommit?)

Mi pregunta es: ¿estoy soñando? Leí hace un tiempo, en un libro de git, creo, que git-svn-clone podría crear repositorios git que son, por supuesto, un "espejo" del repositorio svn, pero que los repositorios git creados de esa manera por diferentes desarrolladores tendrían diferentes " ids "y commits tendrían hashes diferentes. Entonces entendí que esos repositorios git no compartirían ningún antecesor git común, y por lo tanto no podrían usar todos los comandos git que necesitas compartir, unir, etc. ¿Es cierto, vamos a enfrentar problemas con este flujo de trabajo?

A veces leo que esto podría hacerse, usando al menos un repositorio de git al descubierto "oficial", que sería el único que se clonaría git-svn, y todos los usuarios de git tendrían que empezar desde este. Entonces necesitas a alguien que esté a cargo de este repositorio central de git, y reúna los cambios entre los desarrolladores de git, antes de enviar todo al repositorio svn. Esta sería la única forma de que los usuarios de git "desconozcan" que el repositorio original de git proviene de svn, y les permitiría usar todos los comandos de git a su gusto. La única persona que necesitaría ser fluida en git y svn (y conocer las advertencias de git-svn) sería el "administrador de combinación" (o como se llame).

¿Estoy completamente mal entendiendo las advertencias de git-svn? ¿Hay alguna forma más simple de hacer esto?

Answer 1

El problema es el paso 4, por supuesto. Un compromiso intenta reproducir su historial local en el servidor. Dcommit pretende que eres un cliente SVN. Ahora, si el código que está comprometiendo no es solo suyo, es algo difícil de comprometer con SVN.

Esto es lo que el guru escribe sobre el asunto:

• En aras de la simplicidad y la interoperación con SVN, se recomienda que todos los usuarios de git-svn clonen, capten y realicen compromisos directamente desde el servidor SVN (el repositorio SVN remoto que es) y eviten todos los clones de git / pull / merge / push operaciones entre repositorios y sucursales de git que se recuperan a través de git svn clone y que también se utilizan para retrotraer conjuntos de cambios al repositorio de SVN remoto.
• El método recomendado para intercambiar código entre git branches y los usuarios es git format-patch y git am, o simplemente git svn dcommit al repositorio SVN.
• Dado que git svn dcommit usa git svn rebase internamente, cualquier git branches a la que git push antes de git svn dcommit en ellas requiera forzar una sobreescritura de la referencia existente en el repositorio remoto. En general, esto se considera una mala práctica; consulte la documentación de git-push para obtener más información.
• No se recomienda ejecutar git merge o git pull en una rama de la que planeamos extraer svn dcommit. SVN no representa fusiones de ninguna manera razonable o útil, por lo que los usuarios que utilizan SVN no pueden ver las fusiones que hayamos realizado. Además, si hacemos git merge o git pull desde una rama git que es un espejo de una rama SVN, git svn dcommit puede comprometerse con la rama incorrecta.
• git clone no clona ramas bajo refs / remotes / hierarchy o cualquier metadata git-svn, o config. Por lo tanto, los repositorios creados y administrados con git-svn deben usar rsync para clonación, en caso de que la clonación deba realizarse.
• No deberíamos usar la opción --mendar de git commit en un cambio que ya hayamos comprometido. Se considera una mala práctica --mendar commits que ya hemos enviado a un repositorio remoto para otros usuarios, y comprometerse con SVN es análogo a eso. Se puede encontrar más información sobre esto en Modificar una única confirmación y Problemas con el historial de reescritura .

Answer 2

Encontré esta publicación de blog que sugiere mantener una rama separada para sincronizar con el repositorio de Subversion, de modo que todavía será posible hacer push / pull en la rama principal.

Answer 3

Hay una herramienta que resuelve el problema de compartir el repositorio de Git sincronizado con el repositorio de Subversion.

SubGit es un espejo bidireccional del lado del servidor Git-SVN.

Uno puede instalar SubGit en el repositorio de Subversion y obtener el repositorio de Git sincronizado automáticamente con SVN:

$ subgit configure $SVN_REPOS
# Adjust $SVN_REPOS/conf/subgit.conf to specify branches, tags and other options;
# Adjust $SVN_REPOS/conf/authors.txt to specify git & svn authors mapping
$ subgit install $SVN_REPOS
...
$ INSTALLATION SUCCESSFUL

SubGit instala anzuelos precompromisos y postcompromisos en el repositorio de Subversion, ganchos pre-recibidos y post-recepción en el repositorio de Git. Como resultado, traduce inmediatamente las modificaciones entrantes de los lados SVN y Git. Después de la instalación de SubGit, los desarrolladores pueden usar cualquier cliente de Git para clonar y trabajar con el repositorio de Git.

SubGit no depende de git-svn, sino que utiliza su propio motor de traducción que nuestro equipo ha desarrollado. Más detalles sobre esto puedes encontrar en SubGit vs. git-svn comparison. La documentación general sobre SubGit está disponible here .

La versión 1.0 de SubGit necesita acceso local al repositorio de Subversion, es decir, los repositorios SVN y Git deben residir en el mismo host. Pero con la versión 2.0 vamos a introducir el modo proxy de Git, cuando los repositorios Subversion y Git se pueden ubicar en cualquier lugar y solo los repositorios Git tienen SubGit instalado en ellos, es decir, los repositorios de Subversion permanecen intactos.

SubGit es un producto comercial. Es gratis para proyectos académicos de código abierto y también para proyectos con hasta 10 committers.

Descargo de responsabilidad: soy uno de los desarrolladores de SubGit.

Answer 4

He estado experimentando mucho con esto últimamente, y creo que logré encontrar una configuración que funcione de alguna manera. Sí, es un régimen estricto de solo rebase, sí, es complicado, pero puedes usar Git para trabajar localmente (velocidad, historial, escondite, índice, etc.).

Puede usar ramas entre bastidores cuando colabora con otros usuarios de Git en su equipo, creo, pero personalmente no ha experimentado demasiado con esto. Mientras linealices el registro antes de enviarlo, debería funcionar.

Aquí está la versión corta (repite mucho de lo que ya se ha dicho):

1. Clona el repositorio de Subversion en un repositorio de "recuperación" en un servidor central
2. Inicie un repositorio "vacío" en el mismo servidor
3. Empuje desde el repositorio fecthing al repositorio desnudo
4. Haga que los desarrolladores clonen el repositorio desnudo y luego
   5. git svn init svnurl para configurar el control remoto git-svn, y
   6. git update-ref refs/remotes/git-svn refs/remotes/origin/master así que git-svn tiene un puntero a una revisión
5. Automáticamente (commit hook) tiene la función "fetching" repo svn rebase, y presiona al repositorio simple
6. Los desarrolladores sacan del repositorio git pull --rebase con git pull --rebase
7. Los desarrolladores que ejecutan git svn dcommit primero tienen que repetir la update-ref anterior en caso de nuevas revisiones provenientes de SVN.

Hay una ilustración del flujo de trabajo en esta página (necesito más puntos de reputación antes de poder alinear la imagen). Actualización: Aquí vamos:

Answer 5

Lo que solía hacer era crear un git svn clone inicial, y luego compartir el .git entre los desarrolladores usando git, así que teníamos exactamente las mismas referencias.

Parecía funcionar correctamente, ya que pudimos usar "funciones de git específicas" entre los usuarios de git, siempre y cuando permaneciéramos en un árbol lineal (es decir, rebase en lugar de fusionar).

Answer 6

Tan pronto como avances en el problema "distribuido", estarás mejor con un repositorio git al descubierto clonado entre desarrolladores.
En cuanto a la fase de exportación e importación al repositorio SVN público, para que otros utilicen, los guiones
git2svn y svn2git pueden ayudar a encapsular la magia.

Otras consideraciones al trabajar en repositorios de Git y SVN se encuentran en la pregunta "Flujo de trabajo y ayuda con git, 2 proyectos svn y una sola" copia de trabajo ""

Answer 7

Uno de los problemas que percibo con git-svn es que almacena git-svn-id en el comentario de confirmación; porque esto reescribe ese compromiso, cambia su SHA1, por lo que no puede empujarlo a ningún lado, la gente lo compartirá.

De hecho, prefiero bzr-svn porque en su lugar almacena el bzr revid en la revisión de SVN remota utilizando la característica de propiedades de revisión de SVN, lo que significa que no hay reescritura de revisión local. También tiene la propiedad deseada, que dos extracciones independientes de la misma rama SVN darán lugar a ramas bzr idénticas e interoperables.