subgit - migrar svn a git

¿Cuánto del poder de git se pierde usando git-svn y una línea troncal de subversión compartida?

Question

Estoy evaluando varias opciones para alejar a nuestro equipo de CVS. Tenemos otro gran equipo en otro sitio que usa Subversion, y algunos de nuestros desarrolladores trabajan con el servidor de Subversion. Por lo tanto, Subversion es una opción obvia para nuestro equipo. Sin embargo:

1. Las operaciones que involucran al servidor de Subversion pueden ser lentas para el café (aunque tenemos una buena conexión entre los sitios).
2. Muchos de nosotros vendemos la idea del control de versiones distribuidas, y usamos Mercurial o git extensivamente (y luego nos fusionamos y nos comprometemos con CVS y tomamos los cambios de

git-svn parece interesante, pero lo que me gustaría saber es qué parte del poder de un DVCS, como git, se pierde al tener un puñado de ramas centralizadas en Subversion. En particular, aún me gustaría poder mantener el tipo de flujo de trabajo que tenemos con Mercurial, como por ejemplo:

1. ¿Podemos extraer los repositorios de otros miembros del equipo y fusionarnos, y así colaborar en las ramas de características antes de que se dirijan a nuestro principal tronco estable en Subversion?
2. ¿Podemos esperar que la gran cantidad de trucos posibles con git funcione en general, o tenemos que tener cuidado para evitar confundir a git-svn?
3. ¿Podemos usar git para acelerar los pagos de Subversion al tirar de él a través de la conexión desde el otro sitio una vez y luego extraerlo en repositorios individuales una vez?
4. Si alguien se compromete con Subversion, ¿podemos organizar que otros usuarios de git a través de git-svn sigan viendo el historial completo de desarrollo?
5. ¿Podemos básicamente evitar tener que esperar a las operaciones interactivas en el servidor de Subversion a pesar de tener medio mundo de latencia?

Muchos de nosotros estamos acostumbrados a la idea de una rama compartida principal bastante estable con una historia lineal simple a la que todos pueden acceder, y por eso se unen al consejo con regularidad. No me queda claro cómo apoyar bien este flujo de trabajo con git (o Mercurial o Bazar).

Answer 1

Como ya se mencionó, git-svn tiene ciertas limitaciones en comparación con la experiencia pura de Git:

1. La colaboración en equipo es difícil:

   Si un desarrollador empuja cambios al repositorio SVN con git-svn , el otro obtiene cambios ligeramente diferentes; los commits recuperados se convirtieron dos veces, de Git a SVN y de SVN a Git. Como resultado, es difícil colaborar de forma distribuida.

2. Metadatos perdidos

   Los archivos .gitignore y .gitattributes se pierden cuando git-svn envía cambios a SVN, es decir, git-svn no convierte esos metadatos a las propiedades de Subversion correspondientes. Otros desarrolladores no reciben cambios de metadatos en fetch.

3. Datos perdidos de seguimiento de fusión:

   Si uno fusiona dos ramas con git y luego empuja la combinación merge con git-svn , el repositorio de Subversion no obtiene ningún dato en el historial fusionado automáticamente.

4. Soporte de ramificación débil

   Uno tiene que crear una rama en el repositorio de Subversion, buscarla con git-svn y solo entonces realizar cambios en esta rama. Si uno crea una rama Git normal e intenta llevarla de vuelta al repositorio SVN, git-svn no crea una nueva rama, sino que envía las confirmaciones a la existente.

SubGit es una alternativa a git-svn con las siguientes características:

• SubGit funciona en el lado del servidor como un conjunto de ganchos, sincroniza los repositorios SVN y Git manteniendo ambos lados escribibles;

• Se puede usar cualquier cliente de Git para trabajar con el repositorio de Git habilitado por SubGit; cualquier flujo de trabajo de Git es compatible;

• SubGit corrige todos los problemas de git-svn mencionados anteriormente.

SubGit es un software comercial con muchas opciones gratuitas. Para obtener más información, consulte la documentación y la comparación con git-svn .

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

Answer 2

Pierdes mucho, y parece una especie de segunda clase, pero ganas todas las maravillosas ramificaciones.

Aprendí git al usarlo para trabajar en un proyecto alojado en subversión. git me permitió hacer todo mi desarrollo local y progresar bastante en el proyecto mientras seguí el seguimiento de la rama principal e incluso compartí mi trabajo con otros.

Al final, terminamos empujando todo el proyecto a git debido a toda la información que se perdió al ir a la subversión.

Lo que pierdes

1. Seguimiento de fusión: más o menos.
2. Registro apropiado de la autoría de los cambios.

Digo "algo así como" WRT # 1 porque si mantienes un árbol unido, rastreará las fusiones y las cosas que hiciste con git y aplicará a la subversión, pero una vez que tratas de clonar ese repositorio, o alguien más hace un git -svn clon, pierdes eso y las fusiones se vuelven realmente dolorosas otra vez.

Las cuestiones de autoría me importan mucho, porque me parece muy importante asegurarme de que las personas obtengan crédito por el trabajo que realizan.

Answer 3

Por lo que he visto, puedes usar git entre recuperación de repositorio con git-svn (para que puedas tener un repositorio público git que sería el "espejo" del repositorio svn del que hablas, pero el repositorio git podría ser alojado en tu sitio).

Por lo tanto, checkout / clone / push / pull para usuarios de git será rápido. Entonces supongo que puedes agregar ganchos a tu git repo para sincronizar con svn repo a través de git-svn, pero tendrás que lidiar con el conflicto hasta que uses diferentes ramas.

Lo que hacemos aquí es que cada desarrollador tiene una rama con su nombre y tiene que fusionarse con la rama principal (para manejar el conflicto) antes de que un administrador fusione su rama con el maestro, sin ningún conflicto ya que el desarrollador ya lo maneja .

Espero que esto ayude.