Ma petite entreprise

J'ai longtemps utilisé PRCS pour gérer mes projets (développés de manière indépendante, ce qui est le cas le moins complexe), et j'en étais très satisfait, car il était simple d'utilisation, ne polluait pas mon projet avec plein de dossiers .CVS, et ne m'a jamais corrompu mon historique. Cela dit, il ne permettait pas d'avoir un dépôt distant, et rendait difficile l'accès public au "bleeding edge" de mes projets. Après plusieurs années de bons et loyaux services, j'ai donc décidé de passer à atre chose.

Une fois que Subversion a atteint la version 1.0, je me suis mis à l'utiliser. J'ai certes commencé à avoir des dossiers .svn partout (eh oui, il fallait montrer l'héritage de CVS !), mais j'y gagnais la possibilité de partager plus facilement mon code, et l'utilisation en était relativement simple, si ce n'est le fait d'avoir a taper de longues lignes de commande pour accéder à mon dépôt et aux différentes versions. Une des choses que j'appréciais beaucoup était que pour créer une branche, ou créer une version particulière, il suffisait de copier le "trunk" (version courante) a un autre endroit (comme "version/1.0"). Simple et efficace. Cela dit, j'ai eu au bout d'un moment des corruptions de dépôt, avec incapacité a faire un checkout de mes données... le problème s'est répété plusieurs fois, notamment lors de travail alterné sous Linux et OSX (qui ne gèrent pas la casse de la même manière) j'ai donc décidé d'essayer autre chose.

Je suis tombé ainsi un peu par hasard sur Monotone, dont le concept fondamental me plaisait beaucoup : une version d'un fichier correspond à sa signature SHA-1. Ceci permet de s'abstraire de la notion de chemin, de détecter plus facilement les déplacements/renommages, et donne une maniere uniforme de gérer le contenu. Globalement, Monotone m'a beaucoup plu, mais je le trouvais un peu complexe a utiliser, et un peu parano dans sa maniere de gerer les commits (mots de passe à entrer tout le temps; et signatures incessentes). En outre, il n'y avait pas d'interface web, et il était nécessaire d'avoir un serveur pour partager le dépôt.

Après un bref retour à Subversion (et ces mêmes problèmes), j'ai décidé d'essayer darcs. Au départ, j'ai surtout été attiré par la simplicité d'utilisation, et le fait de pouvoir mettre son dépôt à disposition par HTTP. Ensuite, j'ai regardé la manière dont est stocké le dépôt dans le projet, et j'ai trouvé que c'était très simple, et que je pourrais facilement récupérer mes données en cas de corruption. Bref, c'est finalement Darcs que j'utilise pour tous mes projets depuis plusieurs mois, et je suis relativement satisfait (si ce n'est encore de petits problèmes ergonomiques qui persistent).

Entre temps, git a fait son apparition et a plutôt mûri. Sa conception s'inspire notamment de Monotone et de Darcs, mais a essayé de faire quelque chose de plus "essentiel". L'idée principale est que GIT est un "gestionnaire d'historique d'arbre", et offre ainsi un nombre de commandes de base, qui sont ensuite enrobées (wrapped) dans de la "porcelaine" -- la porcelaine étant des commandes de haut-niveau donnant la "tonalité" du système de contrôle de version.

Ainsi, on a pu voir notamment une version de Darcs utilisant git comme back-end. J'ai décidé de gérer quelques courts projets sous Git, qui m'a laissé une impression plutôt bonne, bien qu'il soit assez clairement réservé aux "hackers". Parmi les points positifs, il y a gitk (voir ci-dessous), qui est une interface graphique très utile pour git, et qui permet de s'y retrouver très rapidement - beaucoup plus rapidement qu'avec des outils en ligne de commande. Ensuite, git permet de faire vraiment beaucoup de choses, a condition de "mettre les mains dans le cambouis".

Mais c'est finalement ce que je reprocherais à git : il est trop complexe. Il y a beaucoup trop de commandes disponibles, et la terminologie est très dense, avec une multiplication de termes qui ne sont pas vraiment définis formellement quelque part. Un bref tour sur le canal IRC de git m'a permis de me convaincre du "flou artistique" dans lequel git a été conçu.

Ma conclusion est donc que git est intéressant, car il reprend et résume les innovations apportées par Monotone ou Darcs, mais reste complexe à utiliser, voir un peu confus. Darcs reste pour l'instant ce que je recommande, car il est simple, clair, et de plus en plus utilisé. Je devrais aussi mentionner bazaaar-ng, qui est extrêmenet simple a utiliser (en plus d'être écrit en Python), mais auquel il manque malheureusement quelques fonctions (les tags)...

En tout cas, nous avons connu ces dernières années une vértiable ébullition des logiciels de contrôle de version, avec un réel apport d'idée. Il est probable que tout ceci retombe un peu, et que l'on puisse prendre du recul par rapport à ces nouveaux projets -- mais pour l'instant, l'heure est encore à l'expérimentation !

^[1]