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 :)
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" 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):
- récupérer les projets (depuis le serveur Subversion) de façon fiable ;
- minimiser les accès au serveur Subversion ;
- 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.