Diferentes clones pueden git-svn del mismo repositorio SVN esperan ser capaces de compartir los cambios a continuación, git svn dcommit?

Question

He leído una gran cantidad de "pasar de SVN a GIT" y otros artículos "de flujo de trabajo git-svn" en la web, y todavía pienso que a menudo se enfrentan con situaciones excesivamente simples. A menudo están dirigidos a chicos que sólo quieren usar Git y cortar de forma local, sin necesidad de utilizar toda la potencia de git, como tirón, ir a buscar, combinar y similares entre varios desarrolladores que todos han clonado el repositorio SVN con git-svn, a continuación, aún esperan a ser capaz de empujar sus cambios en cualquier momento en el repositorio sVN (oficial), y volver a trabajar en git y compartir sus cosas, etc.

Siempre que admiten estos artículos no se puede hacer todo lo que haces en git pura, las consecuencias y las posibles subidas de los tornillos no se explican con claridad (o tal vez sea sólo yo?). Incluso la página del manual de git-svn menciona advertencias, pero no realmente de una manera amplia.

Sobre la base de lo que he leído, me siento que podría haber problemas cuando git-svn se utiliza de esa manera específica, lo que voy a describir a continuación. ¿Puede alguien decirme si tengo razón de esto?

Aquí está el "querido" forma de hacer las cosas:

1. Tenemos un proyecto en un repositorio SVN
2. Un desarrollador git-svn-clone es el repositorio SVN. Él comienza a cortar cosas a nivel local
3. El desarrollador B SVN-git-clone es el mismo repositorio SVN. Comienza a cortar las cosas por su cuenta.
4. Después de hacer eso desde hace algún tiempo, posiblemente añadiendo a desarrolladores C / D / ..., y con otros desarrolladores que hacen svn "estándar" se compromete en el repositorio original, los usuarios git querría compartir su código y hacer todo tipo de la magia git.
5. Cualquiera de esos usuarios Git le gustaría ser capaz de empujar el ahora fusionada cambios a SVN (dcommit?)

Mi pregunta es: ¿estoy soñando? Leí hace algún tiempo, en un libro git creo, que git-svn-clon podría crear repositorios Git que son, por supuesto, un "espejo" del repositorio SVN, pero que los repositorios git creado de esa manera por diferentes desarrolladores tendrían diferente " ids" y se compromete tendrían diferentes valores hash. Así que mi entendimiento era que esos repositorios Git no comparten ningún ancestro común git, y por lo tanto no serían capaces de utilizar todos los comandos git que necesita para compartir, combinar, y así sucesivamente. ¿Es cierto, vamos a tener problemas con este flujo de trabajo?

A veces leo esto podría hacerse, utilizando al menos un repositorio "oficial" git desnuda, que sería el único en ser clonados-svn git, git y todos los usuarios tendrían que empezar forma éste. A continuación, necesita a alguien que está a cargo de este repo central de Git, y recoge los cambios entre los desarrolladores GIT, antes dcommiting todo al repositorio SVN. Esta sería la única manera de que los usuarios git sean "conscientes" de que el repositorio git original, proviene de SVN, y dejaría que los usan todos los comandos de Git, como les gusta. La única persona que tiene que ser fluido en Git y SVN (y sabe de advertencias git-svn) sería el "Administrador de combinación" (o lo que se llama).

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

Answer 1

El problema es el paso 4 por supuesto. Un dcommit intenta volver a escuchar su historia local en el servidor. Dcommit finge que eres un cliente SVN. Ahora, si el código que está dcommitting no es sólo de ti, eso es algo que es difícil de dcommit a SVN.

Esto es lo que la gurú escribe al respecto:

  

  
• En aras de la simplicidad y la interoperabilidad con SVN, es   se recomienda que todos los usuarios git-svn   clon, ir a buscar y dcommit directamente desde   el servidor SVN (el control remoto SVN   repositorio que es), y evitar todo   git-clone / tire / fusionar las operaciones / empujar   entre repositorios Git y ramas   que son recuperados, ya sea a través de svn git   clon y que también se utiliza para empujar   Cambios de nuevo en el SVN remoto   repositorio.
  
• El método recomendado para el intercambio de código entre ramas Git   y los usuarios es git formato de parche y git   Soy, o simplemente git svn dcommit a la SVN   repositorio.
  
• Desde dcommit git svn usa git rebase svn internamente, las ramas que git   git push to antes svn git en dcommit   ellos requerirán forzando una sobrescritura   de que el árbitro existente en el control remoto   repositorio. Esto es generalmente   mala práctica considerada, consulte la   documentación git-push para más detalles.
  
• Ejecutar git merge o git pull no se recomienda en una rama planeamos   git svn dcommit partir. SVN no lo hace   representar funde en cualquier razonable o   de manera útil para que los usuarios que utilizan SVN   no puede ver cualquier fusión que hemos hecho.   Por otra parte, si fusionar o GIT GIT   tirar de una rama git que es una   Espejo de una rama SVN, SVN git   dcommit puede comprometerse con el mal   sucursal.
  
• clon git no clona ramas bajo la refs / mandos a distancia / jerarquía o   cualquier git-svn metadatos o Ajuste. Entonces   repositorios creado y gestionado con   usando git-svn debe usar rsync   para la clonación, si la clonación se va a hacer   en absoluto.
  
• No debemos usar la opción de --amend git commit en un cambio que   ya han dcommitted. Está   mala práctica considerada --amend   se compromete ya hemos empujado a una   repositorio remoto para otros usuarios, y   dcommit con SVN es análoga a la.   Más información sobre esto se puede encontrar   en Modificación de una única confirmación y    href="http://www.markus-gattol.name/ws/scm.html#problems_with_rewriting_history" con reescribir la historia .
  

Answer 2

He estado experimentando mucho con esto últimamente, y que me las arreglé para llegar a una configuración que funciona un poco. Sí, es un régimen estricto de rebase de sólo, sí esto es complicado, pero se obtiene al usar Git para trabajar a nivel local (velocidad, historia, escondite, índice, etc.).

Puede utilizar ramas detrás de las escenas cuando colaborar con otros usuarios Git en su equipo que pienso, pero no ha experimentado personalmente demasiado con esto. Mientras que linealizar el registro antes de dcommitting que debería funcionar.

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

1. Clonar el repositorio Subversion en un "ir a buscar" repo en un servidor central
2. Init un acuerdo de recompra "desnudo" en el mismo servidor
3. Al activar en el repositorio fecthing al repositorio desnudo
4. Haga que los desarrolladores de clonar el repositorio desnudo y luego
   5. git svn init svnurl para configurar el mando a distancia git-svn, y
   6. git update-ref refs/remotes/git-svn refs/remotes/origin/master por lo git-svn tiene un puntero a una revisión
5. Automáticamente (cometer gancho) tienen el "ir a buscar" svn rebase de recompra, y empujar a la cesión temporal al descubierto
6. Los desarrolladores de extracción desde el repositorio desnudo con git pull --rebase
7. Los desarrolladores git svn dcommit salir el primero tiene que repetir el update-ref anteriormente en el caso de las revisiones más recientes procedentes de SVN.

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

Answer 3

Lo que solía hacer, es crear un clon inicial git svn, entonces compartida que .git entre los desarrolladores de git utilizando, así que tenía exactamente las mismas referencias.
Parecía funcionar correctamente, ya que pudimos usar "características específicas" git git entre los usuarios, siempre y cuando nos quedamos en un árbol lineal (es decir, cambio de base en lugar de la fusión).

Answer 4

Tan pronto como entras en el tema "distribuido", que está mejor con un repositorio git desnudo clonado entre los desarrolladores.
En cuanto a la fase de exportación e importación para el repositorio SVN público, por otra, para usar los scripts
git2svn y svn2git puede ayudar a encapsular la magia.

Otras consideraciones cuando se trabaja en Git y SVN repos se encuentran en la pregunta " Flujo de trabajo y ayudar con git, 2 proyectos de SVN y un solo “workcopy” "

Answer 5

Hay una herramienta que soluciona el problema de compartir repositorio Git sincronizado con el depósito de la subversión.

SubGit es un bi-direccional espejo del lado del servidor Git-SVN.

Se puede instalar en SubGit depósito de la subversión y obtener repositorio Git sincroniza 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 pre-commit y post-commit ganchos en depósito de la subversión, pre-recibir y post-recibir ganchos en repositorio Git. Como resultado se traduce inmediatamente modificaciones entrantes de SVN y Git lados. Después de desarrolladores de instalación SubGit pueden utilizar cualquier cliente Git para clonar y trabajar con repositorio Git.

SubGit no se basa en git-svn, que utiliza su propio motor de traducción de nuestro equipo ha desarrollado. Más detalles sobre esto se pueden encontrar en SubGit vs git-svn comparación. Documentación general sobre SubGit está disponible aquí .

Version 1.0 de SubGit necesita acceso local a repositorio Subversion, es decir SVN y repositorios Git tienen que residir en el mismo host. Pero con la versión 2.0 vamos a introducir el modo proxy Git, Subversion y Git cuando repositorios pueden estar ubicados en cualquier lugar y sólo repositorios Git han SubGit instalado en ellos, es decir, los repositorios de Subversion permanecen intactas.

SubGit es un producto comercial. Es libre para open-source, proyecto académico y también para proyectos con hasta 10 committers.

exención de responsabilidad: yo soy uno de los desarrolladores SubGit

.

Answer 6

este post blog que sugiere manteniendo una rama separada para la sincronización con el depósito de la subversión, de manera que todavía será posible hacer push / pull en la rama principal.

Answer 7

Uno de los problemas que percibo con git-svn es que almacena el git-svn-id en el mensaje de consignación; porque este reescribe que cometió, que cambia es SHA1, por lo que no puede empujar a las personas en cualquier lugar que va a compartir.

En realidad, prefiero bzr SVN-porque en lugar almacena el revid bzr en el mando a distancia revisión SVN utilizando las propiedades de revisión SVN característica vez que significa que no reescritura de revisión local. También se ha deseado la propiedad, de que dos tirones independientes de la misma rama SVN resultarán en ramas bzr idénticos e interoperables.