Ils ont choisi Subversion. Et pourtant, ils connaissaient git. Mais ils ont quand même choisi Subversion. Personnellement, je ne connais pas SVN, mais je pratique git depuis longtemps. Je ne chercherai donc pas à alimenter la guerre stérile qui anime les défenseurs de chaque camp. Ha ! si, quand même, juste une chose : lors d’une coupure de courant, j’ai pu continuer de développer sur mon portable, organiser mes révisions, bref, travailler, quand tous les autres regrettaient que la machine à café ne soit pas sur réseau ondulé en attendant que l’électricité revienne. Les joies du mode déconnecté.

Je commence à bien connaître git ; une seule raison pourrait faire que je ne chercherai pas à l’utiliser d’emblée comme gestionnaire de version sur un projet : le degré d’intégration (de non intégration en fait) à la plateforme de développement. git étant totalement orienté « mode console », ils ont eu raison de choisir SVN pour leur nouveau projet multi-plateforme Windows / MacOS / GNU/Linux.

En ce qui me concerne, git-svn m’a ôté toute velléité d’apprendre à utiliser Subversion, puisque je peux bénéficier localement de toutes les qualités de git en m’interfaçant avec le dépôt central SVN. Par contre, j’ai pu observer leur manière d’utiliser Subversion. Et il en est une qui me choque.

"J'ai comme un goût dans la bouche après ma synchro partielle."

Il y a trop de doigts sur une main pour compter le nombre de participants à mon nouveau projet. Du coup, ambiance plateau de développement, agilité et compagnie. Logique. SVN a cette particularité de permettre de se réaligner partiellement sur la version de référence, ou ce qu’on veut en fait. Difficile d’ailleurs de savoir si c’est une fonctionnalité ou un pis-aller. Personnellement, j’imagine que se réaligner était tellement coûteux (est toujours, en fait), et la gestion des branches suffisamment calamiteuses, pour que les mecs de chez Apache se soient dit : « hé ! mais on devrait avoir le droit de ne récupérer que la nouvelle version des fichiers dont les défauts nous empêchent d’avancer ! » D’où, la synchronisation partielle.

Quand je vois la difficulté de mettre en place, tout comme le gain de temps énorme induit par une gestion correcte des dépendances dans une chaîne de compilation, je suis perplexe face à cette idée de synchronisation partielle. Cela revient quand même à dire que le développeur sait exactement ce dont il a besoin en terme de fichier source (et pas de version) pour corriger un problème auquel il est confronté. Moi, ça me scie. Encore, s’il s’agissait d’introduire localement les modifications issues d’un seul commit plutôt que tout ce qui l’a précédé ou ce qui peut le suivre, je dirais « pourquoi pas » (et c’est d’ailleurs sûrement possible avec SVN), si chaque version est un ensemble homogène et cohérent de modifications ayant trait à un unique sujet, etc. ça peut marcher. Mais non, ils vont piocher un fichier au pif (ou presque) et hop ! ils repartent à 300 km/h sur la piste du développement. Le Ministère de la Justice devrait s’employer à déployer cette technique expéditive, ça a l’air de faire des miracles.

De mon côté, je ne m’étonne plus de constater, lorsque je m’aligne, que le dépôt est vérolé. Ça me semble être la conséquence logique de cette idée de synchronisation partielle : on a (peut-être) testé notre modification dans un espace mal déterminé, on ne va pas recommencer sur l’état à jour. On est agiles ou pas ?

Tags: git, SCM, svn, synchronisation partielle