Re: build-farm 300: Speed up the updates from the repository

On 2006-08-23, Roland Levillain <roland@lrde.epita.fr> wrote:
2006-08-23 Roland Levillain <roland@lrde.epita.fr>
Speed up the updates from the repository.
* maintainer/update_unpacked: Try to update a working copy before retrieving it entirely (with a checkout).
Index: maintainer/update_unpacked =================================================================== --- maintainer/update_unpacked (revision 299) +++ maintainer/update_unpacked (revision 300) @@ -12,12 +12,17 @@ while read package url; do echo $package
- # Extract a fresh copy of the project. - rm -rf "$package.new" - svn checkout -q "$url" "$package.new" - mv -f "$package" "$package.old" - mv -f "$package.new" "$package" - rm -rf "$package.old" + # Try to update the working copy first. + svn update $package
+ # If it fails, extract a fresh copy of the project. + if test $? -ne 0; then + rm -rf "$package.new" + svn checkout -q "$url" "$package.new" + mv -f "$package" "$package.old" + mv -f "$package.new" "$package" + rm -rf "$package.old"
j'aurai verifie que svn checkout marche ou fait un truc du genre: svn checkout -q "$url" "$package.new" && \ mv -f "$package" "$package.old" && \ mv -f "$package.new" "$package" && \ rm -rf "$package.old"
+ fi + done < $SVN_PACKAGES )
Sinon c'est cool d'etre nice with the svn server :) -- SIGOURE Benoit aka Tsuna _____ /EPITA\ Promo 2008.CSI Rock & tRoll

Tsuna <tsuna@warszawa.lrde.epita.fr> writes:
On 2006-08-23, Roland Levillain <roland@lrde.epita.fr> wrote:
[...]
+ # If it fails, extract a fresh copy of the project. + if test $? -ne 0; then + rm -rf "$package.new" + svn checkout -q "$url" "$package.new" + mv -f "$package" "$package.old" + mv -f "$package.new" "$package" + rm -rf "$package.old"
j'aurai verifie que svn checkout marche ou fait un truc du genre: svn checkout -q "$url" "$package.new" && \ mv -f "$package" "$package.old" && \ mv -f "$package.new" "$package" && \ rm -rf "$package.old"
Oui, mais bof. Sans un système qui permet de vérifier le comportement de update_unpacked (logs, envoi d'e-mail au mainteneur de la build farm, etc.) ça ne change pas grand'chose. Et a priori, `svn checkout', ça marche dans tous les cas (à la différence de `svn update'), surtout lorsque le répertoire cible a été supprimé juste avant. En fait, il faut comprendre que `svn checkout', c'est juste une solution lorsque `svn update' ne marche plus. Il faudrait vraiment que le build maintainer soit averti lorsque les deux ne fonctionnent plus (ce qui est rare).

On 8/24/06, Roland Levillain <roland@lrde.epita.fr> wrote:
Tsuna <tsuna@warszawa.lrde.epita.fr> writes:
On 2006-08-23, Roland Levillain <roland@lrde.epita.fr> wrote:
[...]
+ # If it fails, extract a fresh copy of the project. + if test $? -ne 0; then + rm -rf "$package.new" + svn checkout -q "$url" "$package.new" + mv -f "$package" "$package.old" + mv -f "$package.new" "$package" + rm -rf "$package.old"
j'aurai verifie que svn checkout marche ou fait un truc du genre: svn checkout -q "$url" "$package.new" && \ mv -f "$package" "$package.old" && \ mv -f "$package.new" "$package" && \ rm -rf "$package.old"
Oui, mais bof. Sans un système qui permet de vérifier le comportement de update_unpacked (logs, envoi d'e-mail au mainteneur de la build farm, etc.) ça ne change pas grand'chose.
Et a priori, `svn checkout', ça marche dans tous les cas (à la différence de `svn update'), surtout lorsque le répertoire cible a été supprimé juste avant. En fait, il faut comprendre que `svn checkout', c'est juste une solution lorsque `svn update' ne marche plus. Il faudrait vraiment que le build maintainer soit averti lorsque les deux ne fonctionnent plus (ce qui est rare).
Si il n'y a plus besoin svn update il n'y a peut être plus besoin d'une working copy ? Dans ce cas un svn export serais plus efficace. -- Nicolas Pouillard aka Ertai <ertai@feydakins.org> http://uttk.org Uttk -- Unified Test Tool Kit

"Nicolas Pouillard" <nicolas.pouillard@gmail.com> writes:
On 8/24/06, Roland Levillain <roland@lrde.epita.fr> wrote:
Tsuna <tsuna@warszawa.lrde.epita.fr> writes:
On 2006-08-23, Roland Levillain <roland@lrde.epita.fr> wrote:
[...]
+ # If it fails, extract a fresh copy of the project. + if test $? -ne 0; then + rm -rf "$package.new" + svn checkout -q "$url" "$package.new" + mv -f "$package" "$package.old" + mv -f "$package.new" "$package" + rm -rf "$package.old"
j'aurai verifie que svn checkout marche ou fait un truc du genre: svn checkout -q "$url" "$package.new" && \ mv -f "$package" "$package.old" && \ mv -f "$package.new" "$package" && \ rm -rf "$package.old"
Oui, mais bof. Sans un système qui permet de vérifier le comportement de update_unpacked (logs, envoi d'e-mail au mainteneur de la build farm, etc.) ça ne change pas grand'chose.
Et a priori, `svn checkout', ça marche dans tous les cas (à la différence de `svn update'), surtout lorsque le répertoire cible a été supprimé juste avant. En fait, il faut comprendre que `svn checkout', c'est juste une solution lorsque `svn update' ne marche plus. Il faudrait vraiment que le build maintainer soit averti lorsque les deux ne fonctionnent plus (ce qui est rare).
Si il n'y a plus besoin svn update il n'y a peut être plus besoin d'une working copy ? Dans ce cas un svn export serais plus efficace.
En fait, on souhaite (dans cet ordre): 1. récupérer les projets (depuis le serveur Subversion) de façon fiable ; 1. minimiser les accès au serveur Subversion ; 3. minimiser le trafic réseau. On essaie d'atteindre 1. en utilisant `svn update', puis `svn checkout' en cas d'échec. Le 2. est atteint en factorisant les accès aux dépôts depuis goa, qui dispatch[1] ensuite les copies de travail via rsync, et en utilisant `svn update' au lieu de `svn checkout' lorsque c'est possible. Enfin, 3. est à peu près atteint grâce à rsync qui minimise (hopefully) les transferts entre goa et les workers. Notes: [1] « spatch! »

On 8/25/06, Roland Levillain <roland@lrde.epita.fr> wrote:
"Nicolas Pouillard" <nicolas.pouillard@gmail.com> writes:
On 8/24/06, Roland Levillain <roland@lrde.epita.fr> wrote:
Tsuna <tsuna@warszawa.lrde.epita.fr> writes:
On 2006-08-23, Roland Levillain <roland@lrde.epita.fr> wrote:
[...]
+ # If it fails, extract a fresh copy of the project. + if test $? -ne 0; then + rm -rf "$package.new" + svn checkout -q "$url" "$package.new" + mv -f "$package" "$package.old" + mv -f "$package.new" "$package" + rm -rf "$package.old"
j'aurai verifie que svn checkout marche ou fait un truc du genre: svn checkout -q "$url" "$package.new" && \ mv -f "$package" "$package.old" && \ mv -f "$package.new" "$package" && \ rm -rf "$package.old"
Oui, mais bof. Sans un système qui permet de vérifier le comportement de update_unpacked (logs, envoi d'e-mail au mainteneur de la build farm, etc.) ça ne change pas grand'chose.
Et a priori, `svn checkout', ça marche dans tous les cas (à la différence de `svn update'), surtout lorsque le répertoire cible a été supprimé juste avant. En fait, il faut comprendre que `svn checkout', c'est juste une solution lorsque `svn update' ne marche plus. Il faudrait vraiment que le build maintainer soit averti lorsque les deux ne fonctionnent plus (ce qui est rare).
Si il n'y a plus besoin svn update il n'y a peut être plus besoin d'une working copy ? Dans ce cas un svn export serais plus efficace.
En fait, on souhaite (dans cet ordre): 1. récupérer les projets (depuis le serveur Subversion) de façon fiable ; 1. minimiser les accès au serveur Subversion ; 3. minimiser le trafic réseau.
On essaie d'atteindre 1. en utilisant `svn update', puis `svn checkout' en cas d'échec. Le 2. est atteint en factorisant les accès aux dépôts depuis goa, qui dispatch[1] ensuite les copies de travail via rsync, et en utilisant `svn update' au lieu de `svn checkout' lorsque c'est possible. Enfin, 3. est à peu près atteint grâce à rsync qui minimise (hopefully) les transferts entre goa et les workers.
Pas de problèmes. -- Nicolas Pouillard aka Ertai <ertai@feydakins.org> http://uttk.org Uttk -- Unified Test Tool Kit
participants (3)
-
Nicolas Pouillard
-
Roland Levillain
-
Tsuna