Utiliser Eclipse derrière un proxy à la con

Vous connaissez les proxy à la con ? C’est une spécialité des grandes boîtes françaises qui ont une vision assez … restrictive … de ce qu’est un « bon » usage d’internet.

Par exemple, j’ai dû il y a peu installer un Eclipse pour me connecter à un serveur Subversion chez un client qui n’autorise pas l’accès à bintray. Pas grave ? Ca dépend.

Par habitude, j’utilise Subclipse. Or, récemment, ils ont changé leur hébergement pour passer .. chez bintray. Du coup, le plugin n’est plus téléchargeable. Heureusement, eclipse est modulaire, et j’ai pu installer Subversive « facilement » : pour installer Subversive, on installe d’abord le plugin, qui télécharge indépendamment les connecteurs sur un site qui a changé. Ca se passe bien sans proxy à la con. En revanche, dans le cas contraire, il faut télécharger l’update site contenant les connecteurs. Et c’est tout aussi merdique (même si, en fait, Subversive semble mieux que Subclipse – au merge dialog près).

Groovy it, dude !

Je vais faire un peu de live-blogging d’un problème pénible.

Ce matin, je devais faire un merge.

Et curieusement, ce merge foirait, à cause d’une erreur … difficilement compréhensible


Working copy and merge source not ready for reintegration
svn: Reintegrate can only be used if revisions 9043 through 9581 were previously merged from http://achille.perigee.fr/svn16/autocat/autocat-java/branches/2.1 to the reintegrate source, but this is not the case:
autocat-java/branches/2.0-item-196-cc-html5

J’avais trouvé (via Stackoverflow évidement) une méthode manuelle pour corriger le problème. Et j’étais en train de me préparer à faire tout ça à la main en quelques heures.

Et puis je me suis dit que c’est quand même con de corriger une cinquantaine de fichiers à la main quand je peux scripter ça.

Et aussitôt, j’ai lancé ma meilleure Groovy Console pour y écrire ce script, qui fait exactement ce que mentionne la solution : faire un svn propdel sur chaque fichier mentionné.

Et dix minutes plus tard …

Le plus compliqué pour moi a été de me décider : est-ce que j’utilise svnant, ou est-ce que je fais directement de l’exécution shell de « svn » ? Eh bien ce qui m’a poussé vers la deuxième solution,c ‘est que svnant n’est disponible que par téléchargement direct, et que je n’avais pas le courage de voir comment Groovy Grapes allait devoir être configuré pour ça …

En tout cas, ça confirme encore une fois mon opinion sur le fait que Groovy est définitvement LE langage de la JVM pour scripter dans tous les environements.

Erf, Subversion …

Tout part de ce message d’erreur renvoyé par Jenkins (pour bien le comprendre, il faut imaginer que le job Jenkins a créé le tag juste avant, ou presque).

Cleaning up /Jenkins/workspace/ReleaserStep2free/.
Switching to http://subversion/repository/projet/projet-java/tags/1.3/1.3.13 at revision '2014-02-11T15:01:03.996 +0100'
ERROR: Failed to update http://subversion/repository/projet/projet-java/tags/1.3/1.3.13
org.tmatesoft.svn.core.SVNException: svn: E160005: Target path '/projet-java/tags/1.3/1.3.13' does not exist
svn: E175002: REPORT of '/repository/projet/!svn/vcc/default': 500 Internal Server Error (http://subversion)
 at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
 at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
 at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1293)
 at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:833)
 at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doSwitchImpl(SVNUpdateClient16.java:433)
 at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doSwitch(SVNUpdateClient16.java:726)
Caused by: svn: E160005: Target path '/projet-java/tags/1.3/1.3.13' does not exist
 at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
 at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154)
 at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97)
 at org.tmatesoft.svn.core.internal.io.dav.handlers.DAVErrorHandler.endElement(DAVErrorHandler.java:72)
 at org.tmatesoft.svn.core.internal.io.dav.handlers.BasicDAVHandler.endElement(BasicDAVHandler.java:103)
 at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
 ... 24 more
Caused by: svn: E175002: REPORT of '/repository/projet/!svn/vcc/default': 500 Internal Server Error (http://subversion)
 at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
 ... 32 more
ERROR: Subversion update failed

(et encore, j’ai viré des tonnes de lignes).

Donc, je vais voir sur le serveur, et je tombe sur des lignes comme ça à la pelle

[Tue Feb 11 15:12:01 2014] [error] [client 172.27.63.62] A failure occurred while driving the update report editor [500, #160005]
[Tue Feb 11 15:12:01 2014] [error] [client 172.27.63.62] Target path '/projet-java/tags/1.3/1.3.13' does not exist [500, #160005]

Et là, Google ne m’aide pas trop.

Donc je fouille, je fouille, et je tombe sur cette présentation faite lors d’une quelconque conférence Subversion

Subversion error messages demystified

Qui contient en particulier ce slide, que je n’hésite pas à copier-coller ici

www.elegosoft.com_files_Downloads_Subversion_Day_2011_svn-day-berlin-2011_sperli_2014-02-11_17-07-57

Je cite la partie intéressante

Generic server-side error message during updates (could be anything)

Autrement dit, ça sert à rien, mais on l’affiche quand même.

Du coup, je continue à chercher après mon erreur 160005. Au moins, maintenant, je sais que c’est un code d’erreur important.

Bon, ne reculant devant rien, je jette vite fait un coup d’oeil aux codes d’erreurs de Subversion (dans svn_error_codes.h) qui m’envoie tout droit aux codes d’erreurs Apache (à cause de #include <apr_errno.h>)

Et là, un peu d’arithmétique : les codes d’erreur Subversion sont construits à partir de APR_OS_START_USERERR  (qui vaut d’après Apache et d’après mes calculs… 120000 ?)

Comme SVN_ERR_CATEGORY_SIZE vaut 5000, je dois être dans la … (160000-120000)/5000=8 ème catégorie d’erreur qui est donc SVN_ERR_FS_CATEGORY_START. Et mon erreur y est la 5ème, c’est-à-dire

00483   SVN_ERRDEF(SVN_ERR_FS_PATH_SYNTAX,
00484              SVN_ERR_FS_CATEGORY_START + 5,
00485              "Invalid filesystem path syntax")

Pardon ?

Mmh … Là, il est vraiment temps de demander aux développeurs de Subversion quelques détails pratiques.