Commentaires sur : De subversion à git

Par : Romain

Romain — Wed, 20 Aug 2008 07:55:02 +0000

Je pense que tu as bien saisis l’intérêt de gestionnaire de version même lorsqu’on travaille seul, permettrant ainsi de garder un historique des versions, ce qui est *très* utile.

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.

Par : Martin

Martin — Tue, 19 Aug 2008 22:38:14 +0000

Actuellement, je travaille essentiellement seul, sur la base de code open source dont je me garde bien de toucher (compte tenu de mes moyens de production limités et de mes ambitions autres), sauf pour y inclure des patches temporaires ou corriger des défauts, que j’essaye de soumettre aux développeurs officiels lorsque j’y pense.

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.

Par : Romain

Romain — Thu, 07 Aug 2008 12:15:11 +0000

La synchronisation avec git peut se faire de façon très similaire à un système centralisé (tu fais un pull depuis le dépôt public qui va merger les changements distants avec les changements locaux, comme svn update, avec détection des conflits).

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

Par : Martin

Martin — Thu, 07 Aug 2008 12:08:01 +0000

Je ne connaissais pas Git. Idée intéressante. Je me demande bien, cependant, comment peut se passer une resynchronisation après une coupure du réseau de la part de l’un des membres, voire de l’ensemble des membres d’un projet, alors que ceux-ci continuent tous à faire des modification, à défaut d’un serveur central. Je devine cependant que l’un des administrateurs du projet doit alors décider quelles parties doivent être conservées, lesquelles remplacées, et lesquelles fusionnées ?

Par : Peerfuse aux RMLL | Romain's blog

Peerfuse aux RMLL | Romain's blog — Mon, 14 Jul 2008 14:25:55 +0000

[...] Romain « De subversion à git [...]