Systèmes de gestion de versions décentralisés


Publié par
Alexandre ALQUIER

27 août 2010

L’hégémonie des célèbres CVS, Subversion ou ClearCase dans le domaine de la gestion de configuration est-elle en passe d’être révolue ? Après plusieurs années de leadership, les outils centraux de gestion de configuration sont confrontés à des problématiques de développement distribué qui les mettent à mal. L’accès à un repository central depuis les 4 coins du globe est contraint par des temps d’accès réseau pouvant devenir très longs, entrainant des pertes de productivité et de confort. Les besoins en performance induisent alors généralement la réplication des repositories à l’aide d’architectures dont la complexité ou le coût incitent de nombreuses organisations à revoir leur stratégie pour adopter de nouveaux outils dît de Gestion de Versions Distribué, « Distributed Version Control System » (DVCS) :

  • Commits locaux donc très performants
  • Mécanisme de synchronisation natif
  • Pas de downtime serveur
  • Historique complet des branches et révisions en local


Parmi différents outils disponibles, deux solutions se distinguent et deviennent les nouveaux standards de fait : Mercurial et Git, tous deux gratuits.

Développé par Linus Torvalds, le célébrissime « inventeur » du noyau Linux, GIT a les faveurs de la communauté la plus large et la plus active, principalement concentrée sur le site Git Hub.
Mercurial quant à lui touche un public plus restreint, mais dispose toutefois d’une solution de hosting en SaaS et d’une communauté non négligeable sur le site Bitbucket, ainsi que des ressources de formation sur hginit.com.

Et si la taille de la communauté GIT est plus importante, le rapport s’inverse concernant la courbe d’apprentissage. GIT fournit un jeu de nouvelles commandes complexes et nécessite motivation et expertise pour démarrer.
Mercurial est beaucoup plus proche de SVN. Les utilisateurs déjà habitués à ce « classique » pourront donc démarrer avec moins d’efforts. C’est d’ailleurs pour cette raison qu’Atlassian (qui possède désormais 4 équipes de développement à San Francisco, au Brésil, en Pologne et en Australie et qui est donc confronté de plein fouet à une organisation de développement distribuée) applique encore une fois la théorie du « eat your own dog food » en lançant un vaste plan interne de migration depuis SVN vers Mercurial.

Du côté de l’IDE les 2 outils proposent un ensemble d’intégrations avec les leaders du marché : IntelliJ, Eclipse et Visual Studio.

IDE Mercurial GIT
IntelliJ MercurialIDEA Native
Eclipse MercurialEclipse EGit
Visual Studio Visual HG GitExtensions

Comme à son habitude, Atlassian souhaite suivre les tendances méthodologiques et entretenir d’excellentes relations avec les communautés innovatrices de l’Open Source, et a donc décidé de supporter ses 2 produits en développant des intégrations avec JIRA, FishEye et Bamboo.

  • Intégration JIRA / FishEye
  • Intégration JIRA / Mercurial avec JIRA Mercurial Plugin pour JIRA 4 et 4.1, Atlassian fournit actuellement un effort important sur ce plugin.
  • Intégration JIRA / GIT à l’aide de l’extension JIRA Git Plugin depuis août 2009, compatible JIRA 3.12 et 3.13.
  • L’intégration Bamboo / Mercurial est en cours de test interne, elle sera mise à disposition dans la prochaine release, en attendant, un plugin est disponible.
  • L’intégration Bamboo / GIT est disponible via un plugin depuis début 2010, compatible avec les versions 2.2 à 2.5.

Enfin, nous avons eu un retour d’expérience concernant la migration de données depuis SVN vers Mercurial par l’équipe de développement Web Task Force d’Atlassian. Les premières tentatives effectuées avec l’outil « built-in » ConvertExtension ont causé de nombreux problèmes (freezes, plantages) ; et le premier test réussi a nécessité 31h pour 270 000 lignes de code. Très peu confiants, ils ont finalement opté pour l’utilisation de hgsubversion, avec lequel la migration test a mis 2h et s’est bien déroulée dès la première tentative. A bon entendeur… :)

Pour en savoir plus :

Sur le blog Atlassian :

Cet article est issu des notes que j’ai prise lors de la présentation Distributed Version Control Systems in the Enterprise de Justen Stepka au Summit Atlassian 2010, décidément riche.