Pour info, les fichiers générés habituellement toutes les heures sont
passées à 6h et 19h ... en effet, chaque génération provoque environ
10 minutes d'interruption de la zone ce qui est un peu génant pour
commiter.
La zone est énorme, il y a surement quelque chose à faire sur la
génération automatique des paquets ... ou sur le serveur ... ou la
version de trac ou ....
Le 25 février 2009 23:42, Ben. . <ben.spip@gmail.com> a écrit :
Pour info, les fichiers générés habituellement toutes les heures sont
passées à 6h et 19h … en effet, chaque génération provoque environ
10 minutes d’interruption de la zone ce qui est un peu génant pour
commiter.La zone est énorme, il y a surement quelque chose à faire sur la
génération automatique des paquets … ou sur le serveur … ou la
version de trac ou …
il me semble que j’avais essaye de passer la mise a jour via un svn up lors du transfert sur le nouveau serveur, je pensais pouvoir limiter l’impact sur le svn
je vais essayer de rebalayer le code. pour la partie shell si certains maitrise je suis preneur, c’est pas mon point fort.
Pour rappel le code des paquets est sur http://zone.spip.org/trac/spip-zone/browser/dev/paquets/bin
le script lancé est grospaquet.sh
a+
Arnaud
Le 26 février 2009 00:09, Arnaud Ventre <ventrea@gmail.com> a écrit :
Le 25 février 2009 23:42, Ben. . <ben.spip@gmail.com> a écrit :
Pour info, les fichiers générés habituellement toutes les heures sont
passées à 6h et 19h … en effet, chaque génération provoque environ
10 minutes d’interruption de la zone ce qui est un peu génant pour
commiter.La zone est énorme, il y a surement quelque chose à faire sur la
génération automatique des paquets … ou sur le serveur … ou la
version de trac ou …il me semble que j’avais essaye de passer la mise a jour via un svn up lors du transfert sur le nouveau serveur, je pensais pouvoir limiter l’impact sur le svn
je vais essayer de rebalayer le code. pour la partie shell si certains maitrise je suis preneur, c’est pas mon point fort.
Pour rappel le code des paquets est sur http://zone.spip.org/trac/spip-zone/browser/dev/paquets/bin
le script lancé est grospaquet.sh
je pense avoir trouvé la partie gourmande :
il y a dans pquets-unique.sh :
svn --force export$revision « $svn_dir » « $work_dir/$paq_root »)
le problème vient des sabots : on ne peut pas avoir de copie de travail locale unique car on traville sur différente révision pour générer les zip pour les archives sur lesquelles des sabots sont poses.
pour résoudre ce probleme on pourrait remplacer les sabots par des tags : la copie locale inègrerait alors les différentes versions sans besoin de mise à jour et cela ne surchargerait pas le serveur juste quelques pointeurs de plus ?
sans ça la creation d’un cache local devient beaucoup plus complexe.
A partir de ce cache local on cree une arbo synchronisee sans les .svn rsync --exclude **/.svn (ou approchant).
Elle sert de repertoire de base pour generer les zip.
derniere option mettre a jour la version du serveur svn pour permettre une replication (à partir de svn 1.4), dans ce cas on remplace la source par son replicat local et le tour est joué.
A+
Trop tard pour réfléchir plus mais je ne vois pas de solutions simple pour l’instant , n’hésitez pas à proposer des idees.
Arnaud
le problème vient des sabots : on ne peut pas avoir de copie de travail
locale unique car on traville sur différente révision pour générer les zip
pour les archives sur lesquelles des sabots sont poses.
On pourrait faire un checkout comme maintenant de chaque répertoire,
mais au lieu de l'effacer ou de l'ignorer au tour suivant, faire un
svn up plutôt qu'un nouveau co
-- Fil
Le 26 février 2009 08:31, Fil <fil@rezo.net> a écrit :
le problème vient des sabots : on ne peut pas avoir de copie de travail
locale unique car on traville sur différente révision pour générer les zip
pour les archives sur lesquelles des sabots sont poses.On pourrait faire un checkout comme maintenant de chaque répertoire,
mais au lieu de l’effacer ou de l’ignorer au tour suivant, faire un
svn up plutôt qu’un nouveau co
Envisageable en intégrant :
-Une gestion de ce cache : on ne peut pas se fier qu’au nom de l’archive
il faut croiser le nom de l’archive et le chemin svn comme clef du cache. Cela peut se traduire par une verification du chemin de la copie locale par rapport à celui de l’archive list avant de faire un up ( à moins que l’astuce du checkout de la racine permette de gérer ça naturellement, à tester).
-Une mécanique de nettoyage (peut se faire par une comparaison du contenu de l’archive list et la liste de caches)
-le filtrage des .svn. Je pense tjs à ma copie via un rsync filtrant (ça double le volume local mais c’est simple à écrire), à moins qu’il soit possible de filtrer des arbos nativement ou via des pipe lors de la creation du zip.
a+
Arnaud