Performances du SVN après de nombreuses révisions

Question

Mon projet utilise actuellement un dépôt svn qui reçoit plusieurs centaines de nouvelles révisions par jour. Le dépôt réside sur un serveur Win2k3 et est servi par Apache/mod_dav_svn.

Je crains maintenant qu'au fil du temps, les performances se dégradent en raison d'un trop grand nombre de révisions.
Cette crainte est-elle raisonnable ?
Nous prévoyons déjà de passer à la version 1.5, de sorte que le fait d'avoir des milliers de fichiers dans un seul répertoire ne posera pas de problème à long terme.

Subversion stocke le delta (les différences) entre 2 révisions, ce qui permet d'économiser BEAUCOUP d'espace, surtout si vous ne livrez que du code (texte) et pas de binaires (images et documents).

Cela signifie-t-il que pour vérifier la révision 10 du fichier foo.baz, svn prendra la révision 1 et appliquera ensuite les deltas 2 à 10 ?

Answer 1

Quel type de repo avez-vous ? FSFS ou BDB ?

(Prenons FSFS pour l'instant, puisque c'est la valeur par défaut).

Dans le cas de FSFS, chaque révision est stockée sous la forme d'une différence avec la précédente. On pourrait donc penser que oui, après de nombreuses révisions, ce serait très lent.

Ce n'est pourtant pas le cas. FSFS utilise ce que l'on appelle des "skip deltas" pour éviter d'avoir à faire trop de recherches sur les révisions précédentes.

(Donc, si vous utilisez un repo FSFS, la réponse de Brad Wilson est fausse).

Dans le cas d'un repo BDB, la révision HEAD (la plus récente) est en texte intégral, mais les révisions antérieures sont construites comme une série de diffs par rapport à la head. Cela signifie que les révisions précédentes doivent être recalculées après chaque livraison.

Pour plus d'informations : http://svn.apache.org/repos/asf/subversion/trunk/notes/skip-deltas

P.S. Notre répertoire est d'environ 20 Go, avec environ 35 000 révisions, et nous n'avons pas remarqué de dégradation des performances.

Answer 2

Subversion stocke la version la plus récente en texte intégral, avec des différences rétrospectives. Cela signifie que les mises à jour de la tête sont toujours rapides, et que ce que vous payez de manière incrémentale est de regarder de plus en plus loin dans l'histoire.

Answer 3

Personnellement, je n'ai pas eu affaire à des dépôts Subversion avec des bases de code supérieures à 80K LOC pour le projet lui-même. Le plus gros dépôt que j'ai eu était d'environ 1,2 gigas, mais il incluait toutes les bibliothèques et utilitaires utilisés par le projet.

Je ne pense pas que l'utilisation quotidienne sera tellement affectée, mais tout ce qui nécessite de consulter les différentes révisions pourrait ralentir un peu. Ce n'est peut-être même pas perceptible.

Du point de vue de l'administrateur système, certaines choses peuvent vous aider à minimiser les goulets d'étranglement en matière de performances. Comme Subversion est principalement un système basé sur des fichiers, vous pouvez le faire :

• Placer les référentiels actuels sur un autre lecteur
• Assurez-vous qu'aucune application de verrouillage de fichiers, autre que svn, ne travaille sur le disque ci-dessus.
• Les disques doivent avoir une vitesse de rotation d'au moins 7 500 tours/minute. Vous pouvez essayer d'obtenir 10 000 tours/minute, mais cela risque d'être excessif.
• Mettre à jour le réseau local pour qu'il soit gigabit, si tout le monde se trouve dans le même bureau.

C'est peut-être exagéré dans votre cas, mais c'est ce que j'ai fait pour d'autres applications gourmandes en fichiers.

Si jamais vous "dépassez" Subversion, alors Perforce sera votre prochaine étape. C'est de loin l'application de contrôle de source la plus rapide pour les très gros projets.

Answer 4

Nous utilisons un serveur subversion contenant des gigaoctets de code et de binaires, et nous en sommes à plus de vingt mille révisions. Aucun ralentissement pour l'instant.

Answer 5

Subversion ne stocke que le delta (les différences) entre 2 révisions, ce qui permet d'économiser BEAUCOUP d'espace, surtout si vous ne livrez que du code (texte) et pas de binaires (images et docs).

De plus, j'ai vu beaucoup de très gros projets utiliser svn et ne jamais se plaindre des performances.

Peut-être êtes-vous préoccupé par les délais de paiement ? Dans ce cas, je pense qu'il s'agirait vraiment d'un problème de réseau.

Oh, et j'ai travaillé sur des dépôts CVS contenant plus de 2 Go de données (code, images, documents) et je n'ai jamais eu de problème de performance. Puisque svn est une grande amélioration de cvs, je ne pense pas que vous devriez vous inquiéter.

J'espère que cela vous facilitera un peu la tâche ;)