On 2006-08-24, Nicolas Pouillard nicolas.pouillard@gmail.com wrote:

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.

Si si on fait des svn up pour avoir des mise a jour incrementielles et ne pas bourriner trop le serveur SVN. Dans certains cas malheureusement, la working copy se lock, et alors dans ce cas seulement, on la rm et puis on re checkout.