Pré-ambule :
Notre gros problème pour la zone c’est que le serveur n’est pas dédié à Subversion, donc les ressources qu’on peut lui affecter sont nécessairement réduites.
Le fait de saturer le serveur est donc « assez facile » et possède un effet de bord trop important pour être considéré comme négligeable : on ne peut parfois plus faire de checkout ni de commit ni accéder à Trac.
Bref l’avantage individuel qu’on peut avoir à faire des vérifs sur toute la zone en une fois pénalise le collectif, ce qui est contraire à la charte de spip-zone.
Maintenant, ceux qui ont de tels besoins peuvent aussi se cotiser pour acheter plus de ressources pour le serveur Subversion 
2009/7/23 RastaPopoulos <vincent@ldd.fr>
Le 23/07/2009 15:31, Gilles VINCENT a écrit :
Je pense qu’on devait interdire de faire des checkout complets de
spip-zone (et même des sous-dossiers principaux !)
Car franchement des utilisateurs qui font ça, ils nous plombent le
serveur à chaque update !!
- Comme si je m’amusais à faire un update de toute la zone régulièrement. C’est une opération qui arrive super rarement. La très grande majorité du temps, je ne fais des update que du plugin que je suis en train d’utiliser.
Tant mieux, mais j’ai déjà vu quelques personnes qui font des updates globaux plutôt que de les faire projet par projet.
Je note que si tu avais tous les projets dans des dossiers non versionnés, ça ne changerait rien pour toi
- C’est expressément voulu d’avoir un checkout complet. J’ai un grand nombre de site de dev en local (dans ~/public_html) et je ne fais AUCUN checkout de plugins dedans. Les plugins de tous ces sites sont des liens symboliques vers le checkout complet de la zone. Lorsque je fais UN update d’un plugin, TOUS mes sites de dev sont à jour.
Donc encore heureux que ce soit possible, c’est justement bien plus simple et demande moins de ressources au serveur puisqu’il n’y qu’un seul update pour tous les sites.
Oui c’est une pratique bien utile.
Mais est-ce que ça implique que tu dois avoir une copie de tout spip-zone ? Je n’en suis pas convaincu.
Il fait les vérifications par rapport à la copie locale qu’il a dans les
.svn, pas sur le serveur (heureusement).
Et ce, en effet, +/- à chaque fois (ça c’est parceque c’est intégré à
l’exploreur de fichier).
Si c’est lent c’est aussi lié à Windows peut-êtreJe n’ai pas Windows, puisque j’ai dit que j’utilisais Ubuntu + Nautilus + je testais le plugin NautilusSVN.
Arf, au temps pour moi : je pensais que tu parlais de TortoiseSVN, mais en relisant tu décrivais un principe plus général
Que ce soit sur l’un ou l’autre des systèmes, il y a le même type de ralentissement puisque dès que j’utilise le checkout de la zone ou PIRE le checkout de mon entreprise (et viens pas me dire qu’il faut pas faire de checkout complet là) et bien ça va vérifier (même si c’est qu’en local peu importe) sur des milliers de fichiers à la fois.
Donc c’est la technique qui cause le ralenti, pas tel ou tel système.
Pour ma part voici l’arborescence non versionnée dans laquelle je mets mes différents plugins.
C’est inspiré d’un pseudo-inventaire que j’avais fais : http://www.mindmeister.com/11093093
spip-zone/
|-- plugins
| |-- administrateurs
| |– cle-en-main
| |– contenu
| |– contributeurs
| |– performance
| |– referencement
| |– securite
| |– squelettes
|
|-- core
|-- squelettes
|-- themes
(avec à chaque fois des sous-dossiers pour séparer les plugins compatibles spip-192 et spip-20)
Quand je navigue dedans, svn fait nettement moins de vérifications car je n’ai pas dans les sous-arbo de sous-projets très lourds ou complètement obsolètes.
L’avantage que j’ai, c’est que j’organise mes plugins comme bon me semble.
C’est pour cela que je pense qu’on peut se passer de récupérer une copie complète de spip-zone.
Ce principe est peut-être aussi valable avec le dépôt de ton entreprise.
A mon avis tu es fautif, au moins autant que ton outils.
Non, ce sont les deux logiciels qui sont mal faits, puisqu’ils lancent une vérification à l’entrée de chaque dossier.
Ils pourraient parfaitement :
- ajouter des emblèmes aux dossiers et fichiers
- ajouter des menus contextuels
Mais PAS faire de « svn status » automatique sans qu’on n’ait rien demandé !
C’est ce que fait Tortoise : les icônes sont pas toujours à jour dans l’explorateur car il ne va rafraichir celui d’un menu que si tu y vas, ou bien après un commit / checkout dans un dossier parent. (tu n’as qu’à regarder les vidéos que j’ai faites pour t’en convaincre)
Si les outils ne font pas ça, en effet c’est vite beaucoup de vérifications qui bouffent des ressources. Et oui c’est stupide.
rien ne vaut la ligne de commande, c’est sûr
Oui. Mais les scripts qui intègrent ces commandes dans le menu contextuel de l’explorateur de fichiers, c’est bien pratique. Ça évite de basculer en permanence sur le terminal.
oui oui, je suis d’accord
.Gilles
