Reste à savoir quel gestionnaire de version utiliser : personnellement j’ai commencé par CVS puis sa version améliorée Subversion. Il y a quelques temps lors du démarrage du projet Domogik, mon collègue m’a proposé d’utiliser Mercurial. Je ne connaissais pas spécialement et j’ai dit “Ok pourquoi pas”. Il m’a vaguement expliqué les différences en me précisant que Mercurial était un gestionnaire de versions décentralisé. Cela n’a pas fait “tilt” chez moi et j’ai à peine relevé la remarque. Lorsqu’on a commencé à travailler, en bon informaticien, je n’ai pas pris le temps de lire la documentation de Mercurial et je me suis dit : “Bon à part la syntaxe des commandes qui change ça reste un gestionnaire de versions”.

Et là grave erreur, j’ai utilisé pendant des mois Mercurial comme j’aurais fait avec Subversion. Du coup j’ai fréquemment pesté envers Mercurial, avec toute la mauvaise foi qui s’impose, avançant des arguments tels que “Mercurial c’est beaucoup trop compliqué pour notre projet” etc. Je dis grave erreur, car par hasard un autre collègue m’a donné le lien vers un excellent tutoriel qui explique les différences fondamentales entre Subversion et Mercurial. Là je me suis dit que j’avais perdu pas mal de temps en sous-exploitant la souplesse offerte par Mercurial. En voici un (très gros) résumé :

• Mercurial est effectivement décentralisé, ainsi chaque développeur possède son propre dépôt (repository). Ainsi vous pouvez effectuer des commits locaux sans affecter le dépôt central tout en bénéficiant d’un historique de vos modifications.
• Mercurial utilise la notion de changeset plutôt que de revision. Cela signifie, en gros, qu’il mémorise l’historique des changements qui ont été appliqués pour passer d’une version à l’autre. Subversion lui mémorise les versions de chaque fichier.
• La notion de fusion (merge) est parfaitement gérée par Mercurial, et je dirais qu’il s’agit même d’une opération qu’on est amené à effectuer assez fréquemment. Si vous êtes plusieurs développeurs qui travaillent sur une même version et que vous effectuez régulièrement des commits sans les publier sur le dépôt central, alors lorsque vous souhaiterez récupérer les mises à jour de vos collègues, un merge sera nécessaire, même si vous n’avez pas travaillé sur les mêmes fichiers (je sais,  lorsqu’on vient du monde de Subversion cela peut paraître étrange, mais vous comprendrez le pourquoi du comment si vous suivez le tutoriel dont je vous parle à la fin). Notons qu’avec Subversion la notion de merge fait souvent peur et doit être appliquée très prudemment, avec Mercurial il y a rarement des soucis.

Bon les différences que j’expose ci-dessus peuvent vous paraître énigmatiques si vous ne connaissez pas Mercurial, mais elles sont fondamentales. Pour ceux qui sont confrontés à la gestion de versions (et qui lisent la langue anglaise), je vous recommande très chaudement cet excellent tutoriel. Après l’avoir lu, alors que j’étais initialement réticent à Mercurial, j’ai été définitivement convaincu sur la supériorité de Mercurial. Il n’est pas plus compliqué à utiliser que Subversion et offre à mon sens beaucoup plus de possibilités.

Bonne gestion de versions !

Références :

• Tutoriel hginit [en]
• Le livre de référence de Mercurial [en]

yum install --enablerepo=updates-testing subversion

svn move myfile1 myfile2
svn commit

Pour plus d’informations sur ce qu’est Subversion vous pouvez consulter l’article Wikipédia ou encore le site officiel (en anglais).

Procédure à suivre :

1) Désinstaller la version actuelle de Subversion

sudo aptitude remove subversion

2) Ajouter ces dépôts dans /etc/apt/sources.list

deb http://ppa.launchpad.net/clazzes.org/ubuntu hardy main
deb-src http://ppa.launchpad.net/clazzes.org/ubuntu hardy main

3) Enfin installer la nouvelle version :

sudo aptitude update
sudo aptitude install subversion