Il a été décidé il y a peu que le projet Peerfuse utiliserait dorénavant le système de gestion de version Git.
Je ne reviendrai pas sur l'intérêt qu'apporte un système de révision distribué (indépendance vis à vis d'un serveur central, l'avantage des branches, facilité pour un contributeur irrégulier de contribuer, etc.).
Je me permets juste de donner quelques opérations à suivre pour importer un dépôt subversion (note: installer préalablement git et git-svn) :
$ mkdir project $ cd project $ git svn init -t tags -b branches -T trunk https://svn.example.org/prjt Initialized empty Git repository in .git/ $ git svn fetch
Et.. c'est tout.
Nous disposons maintenant d'un dépôt git indépendant, contenant l'intégralité de l'historique des commits du subversion. On peut ainsi le mettre à disposition pour que d'autres en profitent, et se mettre à travailler immédiatement.
Pour plus d'informations sur comment utiliser git, je préfère vous laisser vous référer à la très bonne documentation de Git.
Je profite de ce bref billet pour rappeler que Peerfuse a besoin de contributeurs.
À ce propos, une conférence se déroulera aux RMLL08 sur Peerfuse, ainsi n'hésitez pas à la regarder si vous êtes intéressé par le projet.
En général, il vaut mieux avoir la branche master à laquelle tu ne touches pas et que tu synchronises fréquemment avec le dépôt public, et tu crées une branche pour faire un développement spécifique, à la fin tu fais un merge des deux branches, et tu résous les conflits.
Ensuite, l’avantage de git je trouve est que tu as divers moyens d’envoyer tes patches. Si tu as un accès en écriture sur le dépôt public, pas de problème, tu pousses (push), sinon tu as un système qui permet d’envoyer un mail à un dev qui y a accès, et lui, à partir du mail, extrait les commits, et peux les pousser.
Ça permet de simplifier les contributions des personnes n’ayant pas [encore] d’accès en écriture sur le dépôt public.
Par exemple, sur Peerfuse, un contributeur a fait divers patches envoyés par mails que j’ai poussé très simplement (deux commandes suffisent) :
http://peerfuse.net/cgi-bin/gitweb.cgi?p=peerfuse.git;a=log
Cependant, comme je travaille seul, je n’utilise pas de système de contrôle de versions. Je comprends bien son utilité, même pour un unique développeur, mais je me suis rendu compte que les outils dont je disposais ne s’emboîtaient pas bien entre eux. Ainsi, mon outil préféré étant Perforce (gratuit pour les projets open source ou les projets jusqu’à deux développeurs par base) s’intègre mal avec mon environnement de développement, Eclipse ou autre branche non officielle (Aptana Studio en ce moment). En effet, j’aime cet IDE pour une GUI équivalente entre l’ensemble des systèmes d’exploitation supportés, de sorte que je retrouve mes marques sous Mac OS X, mon environnement de développement principal, et Windows que j’utilise encore pour réaliser des tests. Sait-on jamais, je me pencherai sur Linux un jour prochain ?
Toujours est-il que les outils annexes au gestionnaire de versions sont très utiles, et il est difficile d’acquérir des réflexes lorsqu’on doit en utiliser une pléthore, comme un outil pour la visualisation des branches, un autre outil pour le parcours des fichiers, un troisième pour les soumissions et récupérations, et encore un pour la gestion des soumissions par email.
Pour en revenir aux corrections de bugs que je fais, dont une voici quelque temps soumise à l’équipe de WordPress, je passe alors par l’outil de rapport de bugs, ce qui a l’avantage de ne pas avoir à installer un nouvel outil sur son poste de travail et d’apprendre à l’utiliser. Certes, ce mode de fonctionnement n’est possible que si les corrections ou modifications sont minimes, et non des modifications effectuées sur un ensemble de fichiers.
J’utilise d’ailleurs également un dépôt subversion pour mes fichiers de configuration utilisateur (zsh, vim, screen, etc), ce qui me permet d’une part de garder trace de mes modifications, et d’autre part de permettre un déploiement aisé sur les différentes machines (desktop ou serveur) auxquelles j’ai accès.
Pour l’intégration à Eclipse, sache qu’il existe un plugin Subversion (ou même peut-être est-ce de base ? Je ne sais pas, je n’utilise pas Eclipse) qui permet d’avoir une intégration complète. Par contre, un développeur de Peerfuse qui utilise également cet IDE s’est offusqué de n’avoir pu trouver d’équivalent avec Git.
Git est très pratique pour les contributions spontanées et occasionnelles, car tu effectues tes commits en local, tu crées les patches avec une commande (git format-patch origin), et enfin tu les envoies directement par mail avec la commande git send-email.
J’ai d’ailleurs tenté d’imaginer une distribution Linux orienté contributeurs, où pour chaque paquet tu peux choisir entre installation binaire ou depuis les sources (jusque là Debian le fait), mais l’utilisation des sources seraient faites à partir d’un outil tel que Git. Tu peux ainsi effectuer tes patches, une commande te permettrait d’envoyer tes patches au mainteneur du paquet qui se chargerait de les remonter upstream.
Cet outil s’occuperait également de gérer la bonne synchronisation entre la version packagée et ta version locale lors des mises à jour.
Je pense que ça inciterait grandement les gens à contribuer, moi le premier, car avec un OS tel que Debian, c’est très contraignant de maintenir ses patches. J’ai ainsi plusieurs logiciels que je dois mettre à jour moi même à la main pour ne pas perdre les quelques patches que j’ai effectué dessus.