Qué entendemos por rendimiento

"Rendimiento" en control de versiones es multidimensional: tiempo de clone/checkout, velocidad de log/blame, operaciones de branch, refresco del árbol de trabajo, y escalado de contribuidores concurrentes.

Clone vs checkout

# SVN: rápido para checkout inicial, lento para queries de historia
svn checkout https://svn.example.com/repo trunk

# Git: clone más lento, historia instantánea después
git clone https://git.example.com/repo.git

Operaciones locales

git log --since='1 month'    # local, instantáneo
svn log --limit 100           # round trip de red por query

Operaciones de branch

Cambiar branches en Git actualiza una sola ref y los archivos del árbol de trabajo que difieren. En SVN, svn switch recorre el árbol, contacta al servidor, y reescribe archivos.

Tamaño del árbol de trabajo

SVN puede hacer checkout de subdirectorios baratamente. El análogo de Git es sparse checkout más partial clone.

Tamaño del repositorio a escala

Git almacena historia completa localmente. Para repositorios con cientos de gigabytes de binarios, Git tiene problemas. Herramientas como LFS, partial clone y scalar mitigan.

El modelo centralizado de SVN significa que los clientes solo traen lo que piden.

Escritores concurrentes

SVN serializa commits en el servidor. El modelo distribuido de Git significa que el throughput de commits es por clone.

Ancho de banda de red

Git pushea solo deltas de commits no en el remote. SVN envía solo los archivos cambiados pero por cada commit.

Almacenamiento en el servidor

Los archivos pack de Git usan compresión delta agresivamente.

El veredicto del día a día

Para un proyecto típico de 100k LOC con treinta ingenieros, las operaciones Git se sienten instantáneas y las SVN se sienten lentas.

Donde SVN escala más lejos

• Monorepos masivos de contenido binario.
• Acceso heavy-read.
• Entornos donde el ancho de banda a clientes está restringido.