Ce qu'on entend par performance

"Performance" en contrôle de version est multidimensionnel : temps de clone/checkout, vitesse de log/blame, opérations de branche, refresh de l'arbre de travail.

Clone versus checkout

# SVN : rapide pour le checkout initial, lent pour les requêtes d'historique
svn checkout https://svn.example.com/repo trunk

# Git : clone plus lent, historique instantané ensuite
git clone https://git.example.com/repo.git

Opérations locales

git log --since='1 month'    # local, instantané
svn log --limit 100           # round trip réseau par requête

Opérations de branche

Changer de branches dans Git met à jour une seule ref. Dans SVN, svn switch parcourt l'arbre, contacte le serveur, et réécrit les fichiers.

Taille de l'arbre de travail

SVN peut checker des sous-répertoires bon marché. L'analogue de Git est sparse checkout plus partial clone.

Taille du dépôt à l'échelle

Git stocke l'historique complet localement. Pour des dépôts avec des centaines de gigaoctets de binaires, Git a du mal.

Le modèle centralisé de SVN signifie que les clients ne récupèrent que ce qu'ils demandent.

Écrivains concurrents

SVN sérialise les commits sur le serveur. Le modèle distribué de Git signifie que le throughput de commits est par clone.

Bande passante réseau

Git ne pousse que les deltas des commits non sur le remote. SVN n'envoie que les fichiers changés mais pour chaque commit.

Stockage sur le serveur

Les pack files de Git utilisent agressivement la compression delta.

Le verdict quotidien

Pour un projet typique de 100k LOC avec trente ingénieurs, les opérations Git semblent instantanées et celles de SVN semblent lentes.

Là où SVN scale plus loin

• Monorepos massifs de contenu binaire.
• Accès lecture-intensif.
• Environnements où la bande passante vers les clients est contrainte.