Jusqu'à maintenant, je ne voyais pas l'utilité d'une gestion de versions décentralisée mais ayant repris quelques petits développements entre la maison et mon temps de pause au boulot, je me suis retrouvé confronté au problème de la connectivité fluctuante de mon serveur principal, à savoir le FreeBSD de la maison.
En effet, celui-ci n'est pas continuellement allumé en raison de la présence d'un petit être humain au sommeil léger dans mon bureau.
Bien que j'ai commencé à mettre les sources sur mon serveur Subversion, je me suis dit :

Mon petit bonhomme, ne sois pas fermé ! Open your mind !


J'ai donc commencé à regarder les logiciels de gestion de version décentralisé mais un plus particulièrement[1]...

Tout d'abord, regardons de plus près tout ça.

les avantages et inconvénients!!

Commençons par le bien, faut être positif dans la vie :)

Les avantages!!!

LE gros avantage d'un système décentralisé est de pouvoir gérer les développeurs nomades.
Sur un système centralisé, il faut pour toute action ou presque une connexion au serveur. Cela pose problème dans plusieurs cas :

  • Si la connectivité au réseau Internet est omni-présente dans nos contrées, le serveur n'est pas forcément allumé,
  • Dans le cas d'un serveur d'entreprise non connecté au Net et de développeurs nomades, on est coincés aussi.


J'ai personnellement connu le problème avec un développement à l'étranger loin de mon serveur professionnel Subversion à moi que j'ai.
Dans ce cas, pas de possibilité simple[2].
Aujourd'hui, j'ai donc aussi le problème avec le développement à cheval entre la maison et l'extérieur[3].

Comment un système décentralisé peut-il m'aider ?
C'est simple, il permet de faire des commit en local sans connexion et de faire une synchronisation plus tard.
On peut lire à droite à gauche des affirmations que je trouve un peu moins vraies à savoir :

  • La création de branches est beaucoup plus simple que sur les produits centralisés
  • Les fusions[4] entre versions sont plus simples


Pour le premier point, je ne vois pas en quoi cela est vrai. La seule chose, c'est que cela permet la création de branches sans que qui que ce soit ne le sache. Ce point-là, j'aurais tendance à le mettre dans les inconvénients.
Pour le second point, pas mieux. La seule chose est que les systèmes distribués, de par leur architecture, permettent de faire cohabiter ad vitam eternam deux versions filles d'une même version mère et donc de repousser le merge. En effet, en version centralisée, la mise à jour depuis le serveur tente directement le merge et met en conflit les zones modifiées sur le serveur et en local. En découlera dans la suite un inconvénient.

Passons maintenant au côté obscur !

Les inconvénients!!!

Ben oui, faut pas rêver, c'est pas non plus la panacée et puis, j'aime bien être critique.
Alors, les inconvénients sont surtout liés à l'architecture même du système.
En décentralisé, chaque développeur dispose de l'ensemble des fichiers gérés en configuration[5] et peut devenir lui-même serveur de sources. Cela peut sembler un avantage mais dans ce cas, on se trouve potentiellement face à un ensemble de fournisseurs d'un code source ayant au départ la même origine mais contenant chacun des modifications plus ou moins mineures.
Cela permet une grande flexibilité pour la création de branches. Mais pas des branches au sens classique, on parlerai plutôt ici de fork car rien n'oblige le nouveau serveur à se re-synchroniser avec le serveur d'origine.
Avantage ou inconvénient ?
Inconvénient car on peut en arriver à des dérives dont j'ai déjà parlé ici.
Autre inconvénient, cela devient un casse-tête en termes de gestion pure. Où prendre la bonne version ? Qui est le dépositaire DU code ? Il y a donc un risque d'arriver à des discussions style :

Chez moi, ça marche pas Mais t'as la version de qui ? Celle de truc.org Ah ouais mais dans ton cas vaut mieux utiliser celle de dark@vador.net Ah ? Ceci dit, sur la version de yoda@starwars.com, y a des patches intéressants


Un beau bazar quoi !! D'ailleurs, j'ai quelques collègues qui seraient très friands de ce genre de choses[6] au risque de déployer des versions inconnues des autres.

Autre inconvénient lié à l'architecture. Ne pouvant gérer les versions de façon temporelle, celles-ci étant disséminées aux quatre coins de l'Internet, les ''DVCS'' sont obligés de gérer des identifiants uniques de versions de fichiers. Comme ça, ça a l'air anodin mais en fait, cela rend les numéros de version imbitables !!
On est donc obligés d'utiliser une couche permettant la récupération des identifiants en fonction de la date, de l'auteur, du lien de parenté par rapport au code courant...

Reste l'inconvénient lié au merge tardif.
Pourquoi est-ce un problème de repousser la fusion de versions ?
C'est simple, ce sont toujours les mêmes qui se tapent les corvées. En clair, on va se retrouver avec des zigotos qui développent dans leur coin sans jamais fusionner et finir par proposer leur version du source totalement décorellée de la vie du reste.
Et qui va se taper le merge ? C'est Bibi[7]!
Quel que soit le système, si on veut pas voir pulluler des versions de droite et de gauche, la fusion des versions est obligatoire et ce n'est jamais une partie de plaisir.

Conclusion!!

Regardons où on en est.
Finalement, les gestions de version décentralisées sont un bon outil tant que l'on respecte certains principes, surtout dans le cas d'un développement professionnel et même en dehors, je trouve que cela demande encore plus d'organisation qu'un développement centralisé.
Si certains aspects sont très intéressants comme les commits locaux, qui font penser à des sortes de savepoint SQL, d'autres comme la possibilité de faire tourner son propre serveur sur la base de sources modifiés issu d'un autre risque fort de semer la confusion.
En somme, ce ne sont que des outils qui ne se substituent en rien à l'organisation du projet géré.

Dans le prochain billet, je parlerai du système sur lequel j'ai des vues...

Notes

[1] Mais j'en parlerai plus tard

[2] A part la génération de X patchs représentant les étapes du développement unplugged

[3] Rassurez-vous, je suis pas geek au point d'aller coder chez les copains pendant une soirée. Je suis plutôt un bon convive ;)

[4] Comprendre merge

[5] Ou au moins les signatures de ceux-ci

[6] Ils se reconnaîtront

[7] Expérience vécue, même sur du centralisé