Por qué migrar

SVN funciona. Ha funcionado durante dos décadas. Pero su modelo centralizado, branching lento y dificultad para integrar con tooling moderno empuja a la mayoría de equipos hacia Git eventualmente.

Dos rutas de migración

• git-svn - puentea los dos sistemas.
• Conversión one-shot - exportar la historia de SVN a Git, congelar SVN, cambiar.

Preparando

# authors.txt
jdoe = Jane Doe <[email protected]>
bsmith = Bob Smith <[email protected]>

svn log --xml https://svn.example.com/repo \
  | grep author | sort -u \
  | sed -E 's/.*>(.+)<.*/\1 = \1 <\[email protected]>/'

Conversión one-shot con git-svn

git svn clone \
    --stdlayout \
    --authors-file=authors.txt \
    https://svn.example.com/repo \
    repo.git

cd repo.git
git for-each-ref refs/remotes/origin/tags --format='%(refname:short)' \
  | while read ref; do
    tag="${ref#origin/tags/}"
    git tag "$tag" "$ref"
    git branch -d -r "$ref"
  done

Push a un host Git

git remote add origin https://gitlab.example.com/team/repo.git
git push -u origin --all
git push origin --tags

Verificar la migración

• Compara conteos de commit.
• Verifica autores y fechas en commits representativos.
• Los conteos de tags y branches deberían coincidir.

Manejar externals

• Vendor el código external al repo.
• Usar submódulos Git.
• Usar gestores de paquetes del lenguaje.

Entrenamiento

Los saltos conceptuales más difíciles SVN-a-Git: el área de staging, historia distribuida, fast-forward vs merge commits, y la realidad de que los commits locales no están "guardados" hasta que se hace push.

Decomisionar SVN

Tras verificar, congela el repo SVN (solo lectura). Mantenlo accesible para auditoría; no lo borres.