La recherche de svn revision semble soudainement lente (puisque svn 1.5 peut-être?)

Question

Peu après la mise à niveau de notre dépôt vers Subversion 1.5, mon équipe a passé une nouvelle application pendant quelques mois avant de revenir brusquement à notre base de code originale. Nos développeurs utilisent TortoiseSVN 1.5.9 et Subversion Client 1.6 (seulement pour svnversion -n) et Subversion 1.5 sur notre serveur. Nos clients se connectent via svn + ssh.

Notre base de code originale intègre le numéro de révision SVN dans le code en utilisant svnversion -n pour interroger la révision actuelle du WC. Soudainement, cette opération est allée à ce que je me souviens prendre une seconde ou deux à 10 secondes (et j'ai vu pire encore à l'intérieur des environnements de développement VM, etc.) Nous avons également connu des retards similaires en remontant et en expérimentant avec SubWCRev de Tortoise et Subversion Client 1.5.

Ce n'est pas un gros problème, mais c'est certainement un désagrément car cette vérification est faite comme une étape de pré-compilation avant chaque opération de construction. En tant que tel, j'aimerais repasser ces quelques secondes hors de notre boucle de rétroaction! Donc, ma question: Est-ce que j'ai été trop loin de mon ancienne base de code ou quelqu'un d'autre a-t-il remarqué un retard pour cette opération?

Si ce retard est un phénomène nouveau, quelqu'un l'a-t-il corrigé? Si c'est le cas, comment?

Answer 1

Dans le red-bean svn book fortement recommandé, ils déclarent que les grandes validations (beaucoup de fichiers dans une validation) peuvent grandement affecter les performances. Avez-vous vérifié un grand nombre de fichiers récemment, disons dans les 100 dernières vérifications?

Answer 2

Je suis d'accord avec John Weldon. Si vous utilisez Apache (http (s)), vous avez la possibilité de ralentir votre commande svn log. Cela arrive sur les commits avec beaucoup de chemins de fichiers modifiés/ajoutés. Une solution consiste à supprimer l'autorisation basée sur le chemin ou à supprimer la révision particulière. Voir plus de détails pour un here:

Toutes cette vérification de chemin peut parfois être assez cher, surtout dans le cas du journal svn. Lors de la récupération d'une liste de révisions, le serveur examine chaque chemin modifié dans chaque révision et vérifie sa lisibilité. [...] Inutile de dire que cela peut prendre beaucoup de temps sur les révisions qui affectent un grand nombre de fichiers. C'est le coût de la sécurité: même si vous n'avez pas du tout configuré un module tel que mod_authz_svn, le module mod_dav_svn demande toujours à Apache httpd d'exécuter des contrôles d'autorisation sur chaque chemin.

Answer 3

Je viens de résoudre un problème comme celui-ci sur mon serveur. Qu'est-ce que vous utilisez pour auth? Une opération checkout, commit ou log est une série de plusieurs requêtes HTTP. Dans le cas d'un affichage de journal, c'est des centaines. Si vous avez une couche d'authentification, elle sera authentifiée à chaque requête. Si vous autorisez un back-end lent qui vous ralentira. Dans mon cas, nous utilisions notre serveur IMAP (un mod_auth_imap personnalisé). Une fois que j'ai ajouté la mise en cache à la couche d'authentification (gardez les paires utilisateur/passe de hachage en place pendant soixante secondes), les choses ont considérablement accéléré: les vérifications prenaient 1,5 minutes et prenaient maintenant trois secondes.

Answer 4

Within (correctement configuré) zsh, vous pouvez essayer dans votre svn dossier racine:

sed -ns "4 p" **/.svn/entries | sort | uniq 

Il donnera la révision de votre dernière mise à jour ou la liste des révisions si votre référentiel est mélangé. Ce n'est pas aussi complet que ce que fait "svnversion", et il peut ne pas être compatible avec toutes les versions svn (le mien est 1.6.16) mais il fait le travail dans certains cas et il est incroyablement rapide (1s vs 3mn dans mon cas !