Cómo manejar la importación de subversión no estándar a Git

Question

Tenemos un repositorio de subversión no estándar que nos gustaría convertir a Git. El problema es que realmente no sé por dónde empezar para asegurarnos de mantener la historia completa, pero no terminamos con un completo desastre.

Nuestro repositorio cuenta con los últimos 6 años de historia para nuestro paquete de productos de empresas y ha pasado por múltiples reestructuraciones. En todos los casos, tenemos una base de código de plataforma central y luego varios proyectos/complementos que se combinan de diferentes maneras en la parte superior de la plataforma central.

El primer par de años se estructuró como:

-- plugin1 
    - trunk 
    - branches 
    - tags 
-- pluginX 
    - trunk 
    - branches 
    - tags 
-- trunk (core platform) 
    - <various sub dirs) 
-- branches (various feature branches of the entire repository) 
    - refactoring1 
    - refactoringX 
-- tags (various tags of customer releases of full respository) 
    - customerX_1.x 
-- vendor (vendor drops and tracking of 3rd party source deps) 
    - 3rd_party_code_A 
    - 3rd_party_code_X 

Con el tiempo hemos añadido un par de directorios son la raíz incluyendo:

-- releases (replaced tags; branches for released stable versions of repos) 
-- sandbox (area for misc projects of interest; should have been new repo) 

Luego limpiar esto y terminó con:

-- trunk 
    - platform 
    - plugin1 
    - pluginX 
-- stable (stable release branches of trunk) 
    - 1.1 
    - 1.2 
-- tags (release points; marks a point on a stable branch) 
    - 1.1.1 
    - 1.1.2 
-- vendor 
-- sandbox 
-- releases (copies of old releases of interest) 

Así que esa es nuestra historia. Lo que queremos terminar es, con suerte, mucho más limpio. En este momento estamos pensando en la base del repositorio git que se ve así (básicamente una copia del directorio 'trunk' anterior).

- platform 
- plugin1 
- pluginX 

Branches: 
    - stable/1.1 
    - stable/1.2 
Tags: 
    - rel/1.1.1 
    - rel/1.1.2 

Nos gustaría poner sandbox y el vendedor en sus propios repositorios. (no estoy seguro de cómo hacer esto, pero tal vez haya una manera de importar solo un subconjunto de un repositorio svn)

En cuanto a las ramas y etiquetas, queremos que el código de 'estable' termine como ramas, el código de 'etiquetas' para terminar como etiquetas en estable.

Para el historial anterior de la estructura original, nos gustaría mantener la mayor cantidad posible de historia, pero no queremos contaminar el nuevo repositorio. Por ejemplo, si pudiéramos mirar hacia atrás y ver los cambios que ocurrieron en las ramas de refactorización, serían geniales pero no absolutamente necesarios.

Actualmente estamos debatiendo cómo proceder y cómo obtener todo reestructurado e importado de una manera limpia. Lo mínimo que necesitamos es una forma de tener un historial completo de la plataforma y el código de complemento en ambas reestructuraciones de repositorio anteriores. Si es posible, también nos gustaría obtener la información estable y de etiqueta de la estructura del repositorio más reciente.

¿Alguien tiene recomendaciones sobre cómo hacer esta importación?

Por ejemplo:

• ¿Es posible mantener el historial completo a través de las reestructuraciones?
• ¿Deberíamos reescribir el repositorio de subversión de alguna manera para limpiarlo antes de la importación y, de ser así, cómo?
• ¿Deberíamos importar el historial completo y luego reestructurarlo en Git y de qué manera?
• ¿Alguna idea de cómo hacer esta importación limpia?

Answer 1

Dependiendo de su situación, git-svn (con la opción predeterminada --follow-parent) podría hacer el truco como está. Lo primero que debe hacer es probar algunas ejecuciones git-svn, explicando cuidadosamente las opciones -T, -b y -t para ayudarlo con la estructura del directorio.

Sin embargo, puede tener problemas con un complicado historial de estructura de directorios.

Recientemente me encontré en una situación muy similar, migrando el código de Subversion de mi empresa a git, donde el historial de SVN había pasado por una reestructuración muy similar a la que está describiendo. En mi caso, también quería separar los proyectos de un repositorio de Subversion en varios repositorios de Git (uno por proyecto).

Pude tomar el camino más fácil, decidiendo que no era crítico migrar más de unos pocos meses de historia, así que para cada proyecto determiné cuál era la primera revisión que git-svn podía manejar con gracia, y a continuación, solo se obtuvo el historial a partir de allí (utilizando git-svn -r). Habiendo manejado migraciones anteriores de VCS (VSS a SVN, 2005), sabía por experiencia que casi nunca se hace referencia a la historia a largo plazo. En cualquier caso, es fácil dejar funcionando el antiguo servidor de Subversion (en modo de solo lectura), de modo que pueda usarse para buscar cosas si es necesario.

No conozco ninguna forma fácil de limpiar el historial de Subversion, que no sea el uso de svndumpfilter para excluir ciertas partes. Sin embargo, si tienes suerte, git-svn hará lo correcto por arte de magia y la historia se verá más limpia en git log que en svn log (debido a la diferencia en la forma en que git mira las ramas y las etiquetas).

En general, la limpieza y integridad de la historia son dos objetivos en conflicto cuando se hace una migración de este tipo. Afortunadamente, ambos están realmente sobrevalorados: ambos apelan a nuestro sentido de la estética más que ser necesidades pragmáticas.

EDITAR: Lado de la limpieza: use la opción --prefix en git-svn, para dar a las ramas importadas un prefijo único, ya que es probable que tenga diferentes convenciones de ramificación en git, y hace que sea fácil de ver la historia svn más tarde.