Booster Eclipse à travers Samba et SVN

Mon environnement de travail est je pense assez commun:
- un PC sous windows
- un serveur de développement sous Linux
- accès  aux sources du projets via un partage réseau et le protocole Samba
- Eclipse
- outil de versionning, SVN dans mon cas
- Gestion du SVN en dehors d'Eclipse (important!!)

J'ai la chance de travailler dans une petite entreprise, le réseau interne n'est pas saturé et nous sommes que 6 sur le serveur de développement, un quad core avec 8Go de Ram et des disques SAS en 15 000tr/min. Pourtant créer un nouveau projet dans Eclipse ou rafraichir un projet existant prend quelques minutes, voir quelques dizaines pour mes collègues. Et j'imagine bien plus de temps dans les plus grosses structures avec un réseau encombré et un serveur massivement utilisé.

J'ai trouvé d'innombrable questions et commentaires sur les forums et les blogs, d'utilisateurs d'Eclipse se plaignant de la vitesse de ce dernier et cherchant des solutions. Et il m'a fallu du temps pour trouver celle que je vais vous présenter.

1. Le maillon faible

Je suis d'accord Eclipse prend un peu de place en mémoire, mais ce n'est pas pire que FireFox. Et avec des sources de travail en local, il est très confortable. Le problème ne vient donc pas de là.
Comme dis plus haut, le réseaux et le serveur ne peuvent pas être mis en cause dans l'environnement où je suis. Il ne reste plus qu'une composante: l'outil de versionning. Je ne m'avancerai pas pour Git et autre car je ne les ai jamais utilisé, mais SVN à la facheuse tendance de créer un grand nombre de dossier et de fichier. Même si Eclipse et suffisament intelligent (ou bien configuré) pour ne pas les afficher, ils sont tout de même parcourus par Eclipse lors d'une création de projet ou d'un rafraichissement.

2. La solution

Ca parait évidant, il faut éliminer le maillon faible, donc supprimer SVN. Non, je ne propose pas de supprimer SVN de votre environnement de travail mais juste de vos sources qui sont utilisées dans Eclipse.
L'idée est de jongler avec 2 versions de vos sources:
- 1 version issue d'un checkout vous permettant de commiter et d'updater votre copie de travail
- 1 version sans aucun fichier SVN pour Eclipse

Le problème principal reste la synchronisation des deux dossiers. Je n'ai pas envisagé une seconde de copier coller les fichiers modifiés un par un. Il y a des outils pour ça et celui que j'utilise s'appelle rsync. Disponible sur plusieurs OS, il permet de synchroniser 2 dossiers ensemble qu'ils soient distant ou non.

a. Copie de travail avec SVN

Je ne devrai peut être pas le rapeller mais la copie de travail issue de SVN s'obtient très facilement avec la ligne de commande suivante:

 
> svn co http://ip_du_serveur/svn/nom_du_projet/trunk trunk_svn

b. Copie de travail sans SVN

Cette opération est très simple, il suffit de faire un rsync entre le dossier trunk_svn et un dossier vide (nommé trunk dans mon exemple) en excluant les fichiers de SVN. C'est à mon sens le point fort de rsync, sa capacité à exclure des fichiers lors d'une synchronisation avec l'option --exclude

 
> mkdir trunk
> rsync --progress -av --exclude '.svn' trunk_svn/ trunk/

On obtien une copie de travail allégée des fichiers génerés par SVN. Il suffit maintenant de créer un projet sous Eclipse en pointant sur le dossier trunk pour apprécier la différence.

c. Synchronisation  de trunk -> trunk_svn

Quand on veut commiter dans le svn, il faut au préalable resynchroniser le dossier trunk avec le dossier trunk_svn. La ligne de commande est très similaire à celle du dessus:

 
> rsync --progress -av  trunk/ trunk_svn/
 

N'oubliez pas non plus de synchroniser trunk_svn -> trunk quand vous faites un update de votre copie de travail.

d. Allez plus vite avec SVN

Si votre poste de travail est en Windows, vous utilisez surement TortoiseSVN. Ce dernier doit également être relativement lent. La solution est d'utiliser SVN également en ligne de commande. J'ai mis un peu de temps à m'y faire mais finalement c'est très pratique.
Voici un petit rappels des fonctions de base de SVN en ligne de commande.

Check Out:

 
> svn co http://ip_du_serveur/svn/nom_du_projet/trunk dossier_de_destination

Vérifier le status de la copie de travail:

 
> svn status
M      apps/frontend/config/app.yml
M      apps/frontend/modules/home/actions/actions.class.php
?      apps/frontend/templates/_sidebar.php
M      apps/frontend/templates/layout_front.php
?      cache/project_autoload.cache
M      config/databases.yml
M      lib/model/ArticlePeer.php
M      lib/model/Categorie.php
X      lib/vendor/symfony
?      web/ulCkEditorPlugin
?      web/sf
M      web/css/main.css
 

M signifie que le fichier est modifié, ? qu'il n'existe pas et X qu'il s'agit d'un SVN externe.
Pour les fichiers précédé d'un X il faut commencer par les ajouter au dépot:

 
> svn add apps/frontend/templates/_sidebar.php
A         apps/frontend/templates/_sidebar.php
 

Il ne reste plus qu'a commiter:

 
> svn ci apps/frontend/config/app.yml apps/frontend/modules/home/action/actions.class.php 
apps/frontend/templates/_sidebar.php apps/frontend/templates/layout_front.php 
lib/model/ArticlePeer.php lib/model/Categorie.php web/css/main.css -m "#268 => ajout de la navbar"
Envoi          apps/frontend/config/app.yml
Envoi          apps/frontend/modules/home/actions/actions.class.php
Ajout          apps/frontend/templates/_sidebar.php
Envoi          apps/frontend/templates/layout_front.php
Envoi          lib/model/ArticlePeer.php
Envoi          lib/model/Categorie.php
Envoi          web/css/main.css
Transmission des données .......
Révision 43 propagée.
 

La mise à jour de la copie de travail se fait avec la fonction

 
> svn up

J'ai utilisé le projet sur lequel je travaille actuellement, utilisant Symfony 1.4, Zend Framework en plugin, quelques composants Symfony 2 en plugins aussi et un grand nombre d'actions et de templates, pour faire mes tests. Certes cette méthode demande un peu plus de temps et de la rigueur mais le gain de performance est tellement visible.