23 Aug
2006
23 Aug
'06
4:32 p.m.
On 2006-08-23, Roland Levillain <roland(a)lrde.epita.fr> wrote:
2006-08-23 Roland Levillain
<roland(a)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
24 Aug
24 Aug
11:39 a.m.
New subject: build-farm 300: Speed up the updates from the repository
Tsuna <tsuna(a)warszawa.lrde.epita.fr> writes:
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 2006-08-23, Roland Levillain
<roland(a)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" 
1:14 p.m.
New subject: build-farm 300: Speed up the updates from the repository
On 8/24/06, Roland Levillain <roland(a)lrde.epita.fr> wrote:
Tsuna <tsuna(a)warszawa.lrde.epita.fr> writes:
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(a)feydakins.org>
http://uttk.org Uttk -- Unified Test Tool Kit
On 2006-08-23, Roland Levillain
<roland(a)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"
25 Aug
25 Aug
10:26 a.m.
New subject: build-farm 300: Speed up the updates from the repository
"Nicolas Pouillard" <nicolas.pouillard(a)gmail.com> writes:
On 8/24/06, Roland Levillain
<roland(a)lrde.epita.fr> wrote:
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! »
Tsuna <tsuna(a)warszawa.lrde.epita.fr>
writes:
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. On 2006-08-23, Roland Levillain
<roland(a)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"
1:50 p.m.
New subject: build-farm 300: Speed up the updates from the repository
On 8/25/06, Roland Levillain <roland(a)lrde.epita.fr> wrote:
"Nicolas Pouillard"
<nicolas.pouillard(a)gmail.com> writes:
Pas de problèmes.
--
Nicolas Pouillard aka Ertai <ertai(a)feydakins.org>
http://uttk.org Uttk -- Unified Test Tool Kit
On 8/24/06, Roland Levillain
<roland(a)lrde.epita.fr> wrote:
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.
Tsuna <tsuna(a)warszawa.lrde.epita.fr>
writes:
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. On 2006-08-23, Roland Levillain
<roland(a)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).
6461
days inactive
6463
days old
4 comments
3 participants
participants (3)
-
Nicolas Pouillard -
Roland Levillain -
Tsuna