Dans le monde des Logiciels Libre et de Linux, les gestionnaires de versions sont omniprésent, et même on pourrait dire partie intégrante de la phylosophie du Libre et de Linux.

Pas de pratique, dans le sens de l’apprentissage de l’utisisation, ou de tutoriel dans ce billet (peut-être une prochaine fois, mais ce n’est pas non plus ça qui manque). Juste une approche de ce principe ancré pour les anciens, mais parfois méconnu des nouveaux linuxiens.

La programmation et le Logiciel Libre

Bien souvent les personnes s’intéressant à Linux le font par choix, et par intérêt porté à l’informatique, et il est probable qu’une partie d’entre eux viennent à s’intéresser à la programmation et scripts en tout genre.

Il est évident que la programmation tient une place importante dans Linux (au sens large du therme), puisque c’est toute une communauté qui contribue au code source de tout ces Logiciels Libre, et non quelques dirigents produisant des binaires parfois obscure. La programmation est donc importante oui, mais on peut y voir différentes façon de programmer.

• De façon fermé, la personne se programme un utilitaire pour ses besoins, encore une fois cela peut être pour des raisons multiples, du « script jetable » c’est à dire très personnalisé, souvent fait rapidement pour répondre à un besoin bien précis, et qu’y n’a pas toujours d’intérêt à être partager, quoique certains petits scripts astucieux vallent à être connu (cf: Mongueurs de perl par exemple).

  D’autre procèderont ainsi pour s’entraîner, ou encore d’autre par choix, ou par obligation professionnel.
  On verra que justement, même pour s’entraîner, il peut être bon de faire le choix d’un gestionnaire de versions et même pourquoi pas de rendre ce code accéssible aux autres.

• De façon communautaire, on adhère à un projet sur lequel plusieurs personnes y travaillent, ou même pourquoi pas en créer un. C’est une façon très répendu de procéder dans le Libre, et dans ce cas, il est incontournable d’utiliser un gestionnaire de version.
• De façon « patch », c’est une façon très jolie de procéder, loin d’être facile et parfois un peu dévalorisé, il s’agit lorsqu’un bug est repéré, ou une fonctionnalité manquante, de la rajouté sous une forme de patch et de la proposer au développeur du projet, se sont des personnes détaché au projet qu’y le propose, d’où le caractère dévalorisant, car ne sont pas rattaché au projet même s’il contribue et parfois de façon très ingénieuse.

Tout ça pour montrer, que à part dans le 1er cas, la programmation se fait collectivement et ouvertement.

Le 3ème cas étant un exemple de la phylosophie du Libre, n’importe qui peut participer à l’amélioration d’un projet, sans forcément connaître avant les personnes le dirigeant.
Et d’autant plus vrai, que la participation peut être autre qu’on pourrait imaginer, par exemple,  la documentation est un point important auquelle il est possible de participer toujours avec l’intermédiaire d’un gestionnaire de version, mais on y reviendra là dessus.

Les gestionnaires de versions et le Libre

Maintenant que le tour d’horizon est fait, on va s’intéresser au gestionnaires de versions eux-même.
Ils sont nombreux, certain connu, d’autre un peu moins, et fonctionnent de façon plus ou moins ‘centralisée’.

Pour en citer quelques un:

• Git : créer par Linus Torvalds en 2005, fonctionnant de façon décentralisée et utilisé pour le développement du noyau de Linux. Il est très utilisé, et j’y reviendrais plus bas, en l’utilisant comme exemple.
• Subversion : (abrégé par SVN) fonctionne quant à lui de façon centralisée, et créer pour remplacer CVS. (projet lancé en 2000)
• Concurrent versions system : (abrégé par CVS) créer en 1986, centralisé lui aussi.
• Bazaar : (abrégé par bzr) sponsorisé par Canonical Ltd. Il appartient à la catégorie des systèmes de gestion de version décentralisée.
• Mercurial : créer en même temps que git (2005).

Je ne vais prendre l’exemple uniquement sur git, mais la plupart fonctionnant plus ou moins sous le même principe (surtout pour les décentralisée comme git).

Git n’est pas difficile à prendre en main, plutôt instinctif dans les utilisations de bases tout en restant complet tout de même.

Il permet d’obtenir tout un historique des modifications de voir les ‘diff’ et de fournir les ‘patch’ de façon rapide. Ses même patch dont je parlais dans les façon de programmer tout à l’heure.
Il permet de gérer les ‘branches’ facilement également. C’est à dire, on peut modifier le projet dans une branche développement par exemple, sans altérer la branche ‘master’ (principal)
Comme c’est un système décentralisé, il permet d’obtenir tout l’historique et branches de façon local (sur votre ordinateur) afin d’y travailler tranquillement, hors ligne.
On peut ainsi ‘cloner’ tout un dépot Git sur son ordinateur. (mais également avec d’autres gestionnaires)

On peut très bien cloner le dépôt du noyau de Linux vous donnant un appercu au moment du clonage du noyau (pour comprendre les codes, c’est une autre histoire par contre :þ)

Git dans la pratique

Maintenant qu’une rapide présentation de Git est faite, il est temps de voir les applications pratique qu’on peut en avoir.
Attention, c’est ‘la pratique’ en ‘théorie’ c’est à dire, pas de commande ici pour utiliser git.

Étant contributeur (à mon modeste niveau bien sûr) de la communauté francophone d’ArchLinux, je vais en prendre l’exemple donc.

Un dépôt git accèssible depuis le web de la communauté francophone est disponible à l’adresse suivante:
http://gitweb.archlinux.fr/

On y trouve principalement le développement de yaourt (en bash), d’archbot (python), du site web (de mémoire c’est le pastebin), ainsi que la traduction francophone de pacman (le gestionnaire de paquetage, comme l’est aptitude/apt-get et compagnie).

On peut par exemple sans être programmeur s’initier à git avec la traduction de pacman (qui évolue avec les versions) afin d’optenir un patch qui peut être envoyer à son mainteneur (chose que j’ai faite).
C’est un exemple parmis d’autre, mais pour apprendre l’utilisation de git, rien de tel qu’une traduction (du moins pour ceux à qui l’anglais ne rebutte pas)

Une traduction de documentation permet de se concentrer sur l’utilisation de git elle même plutôt que sur l’aboutissement d’un code, tout en ayant une application et utilité bien réel.(après tout dépends de vos compétances sûrement, d’autre préfèreront peut être du code).

Une autre façon pour s’initier, pour les personnes codant souvent pour eux même, c’est de créer un dépôt git local tout comme on le fairait pour un projet. D’une part, ça permet de mieux gérer les erreurs, de pouvoir revenir en arrière en cas de gros pépins, et d’autre part c’est un bonne exercice pour cela.

Comme l’intérêt n’étant pas d’avoir un dépôt local, mais bien accessible depuis le net. (et de là on retrouve l’intérêt de bien commenter ses codes)
On trouve sur internet, des hébergements de dépôts Git très sérieux et gratuit. comme github.com, codePlex (Microsoft), Google Code, ou encore sourceforge.
Des nom bien connu pour la plupart.

Si vous ne savez pas lequel choisir pour votre dépôt, je conseille la lecture (en anglais) de ce tableau comparatif : Comparison of open source software hosting facilities (wikipédia).

Conclusion

Je vous avez prévenu, pas une seul ligne de commande quivabien™ pour cela on trouve des tutoriels un peu partout, et peut être j’irai du mien un jour… :þ

Le Libre, c’est aussi coder ouvert et envers la communauté. L’apprentissage de ce genre d’outils et une étape indispensable. Bien sûr, on code avant tout pour soi (pour son plaisir) mais ce n’est pas incompatible avec ‘coder pour la communauté’, le plaisir de coder peut en être d’autant plus important.

Au lieu de réinventer la roue, ou faire une 500 ème distribution Linux, (parfois à se demander si ce n’est pas dans le seul but d’avoir son nom rattaché comme créateur de tel ou tel projet) Apprennons à contribuer au projets déjà existant, pour lequel le maniement de gestionnaire de version est indispensable.

Une des grandes force du Libre est dans la possibilité de contribution ne l’oublions pas.

Articles en rapport:

• OpenTTD sort en version 1.0.0 beta
• Distribution Linux : comment choisir celle qui vous convient
• FireFox 3.5 : un navigateur internet populaire
• Comment contribuer au kernel Linux sans connaissances
• ArchLinux, une distribution abordable pour les curieux
• L’open source au service de l’agriculture du Nicaragua