Index des leçons :
- Leçon 1 : la gestion de version
- Leçon 2 : qu’est-ce qu’un dépôt ?
- Leçon 3 : les logiciels ”clients”
- Leçon 4 : création d’un dépôt
- Leçon 5 : enregistrement de révision
- Leçon 6 : synchronisation de dépôts, mise à jour du répertoire de travail
- Leçon 7 : identifier les différences
- Leçon 8 : la gestion des branches
- Leçon 9 : la fusion de branche
- Leçon 10 : retour vers le passé
- Leçon 11 : patch et collaboration indirecte
Depuis quelques jours nous testons avec plus ou moins de bonheur un nouveau système de gestion de version, Mercurial. Depuis longtemps en effet nous utilisions Subversion, svn pour les intimes, pour le développement de Dotclear, mais pour permettre un peu plus de souplesse dans la gestion des contributions multiples il a été décidé d’expérimenter un autre système. Arrivé à ce point de la lecture, deux cas se présentent :
- Vous n’avez rien compris aux deux phrases qui débutent ce billet, mais parce que vous ne voulez pas me froisser vous avez fait l’effort, louable, de lire encore jusqu’ici.
- Vous attendez la suite avec un petit air entendu du genre « oui, oui, encore un truc qui me concerne pas, j’ai déjà fait le tour de tout ça ! » et vous vous apprêtez à retourner à votre éditeur de code favori[1].
Vous comprendrez donc que je ne m’adresserai ici qu’aux ceussent qui se sont reconnus dans la première proposition, ou ceux qui curieux souhaiteraient tout de même glaner ici ou là une astuce ou une info qu’ils auraient laissé passer, sait-on jamais.
Je vous propose donc, à partir d’aujourd’hui, de débroussailler ces notions jusqu’à une compréhension suffisante pour être capable de participer au développement. Vous serez alors en mesure de proposer des modifications, des corrections, voire même de nouvelles fonctionnalités à apporter à notre cher projet.
Commençons sans plus attendre par la première notion.
La gestion de version
La gestion de version désigne ici un système qui permet de conserver (tout) l’historique des modifications apportées à un fichier ou à un dossier. Par modification j’entends la réelle modification du contenu du fichier, mais aussi, lorsqu’il s’agit d’un dossier, d’un ajout ou d’une suppression d’un fichier ou d’un dossier.
Quel est l’intérêt de conserver l’historique de toutes les modifications décrites ci-dessus ? Eh bien cela permet de se tromper sans risques. Tout simplement. Imaginez que vous modifiez un fichier et qu’après quelques tests vous vous aperceviez que ce que vous avez codé — autre façon de dire écrire avec une syntaxe et une grammaire particulière et souvent assez stricte définie par le langage utilisé, PHP, javascript, HTML et CSS en ce qui nous concerne — ne fonctionne pas du tout. Il suffit alors de revenir à l’étape précédente enregistrée, ce qu’on appelle communément une révision, pour retrouver le dit fichier dans son état initial.
Ce que je viens de décrire pour la modification d’un fichier est également valable pour n’importe quel type de fichier. On peut tout à fait gérer de cette manière les différentes versions d’une image, d’une vidéo ou de tout autre format de fichier. Nous verrons également que quelques outils existent pour identifier les différences apportées entre deux révisions d’un fichier.
Ce que je viens d’expliquer ici est le principal avantage d’un système de gestion de version, mais pas le seul, nous le verrons après. Parmi les systèmes de gestion de version nous avons Subversion et Mercurial. D’autres existent (Git, Visual Source Safe, …) , certains beaucoup plus vieux comme CVS, mais je n’en parlerai pas ici. Tous ces systèmes ont des fonctionnalités et des usages bien spécifiques, mais tous remplissent à minima la gestion de l’historique de modification décrit plus haut.
La gestion de version est fréquemment utilisée dans les projets de développements logiciels, mais peut tout à fait l’être pour l’écriture d’un ouvrage sur le macramé vaudou ou pour le design du site web du cousin marabout sorcier guérisseur ou que sais-je encore.
Conclusion
Ce billet introduit une série qui ne sera sûrement pas aussi austère, vous connaissez mon goût pour les schémas et les illustrations. En attendant, posez d’ores et déjà toutes les questions que vous voudrez dans les commentaires ci-dessous. J’y répondrai tôt ou tard, en fonction des notions qui auront été ou devront être abordées.
Glossaire
Version : état d’un fichier à un moment donné.
Révision : ensemble des états enregistrés des fichiers et dossiers à un moment donné.
Pour en savoir plus
Quelques liens si vous voulez en savoir plus en attendant la prochaine leçon (vous pouvez zapper les deux derniers liens pour l’instant) :
- Logiciel de gestion de versions (Wikipedia)
- Subversion (Wikipedia)
- Mercurial (Wikipedia)
PS : Si certains passages ne vous semblent pas clairs, si vous avez une formulation plus compréhensible, n’hésitez pas à me le dire, je modifierai ce billet et les suivants en conséquence. L’objectif est de faire un tuto compréhensible par le plus grand nombre. D’autre part, si vous avez connaissance d’un tuto identique à celui que je me propose de développer ici, n’hésitez pas à me le signaler, ce serait idiot que je refasse le même travail qu’un autre !
Notes
[1] Textmate est à mon très humble avis un excellent choix sur Mac OS X, bien que les plus purs des geeks ne connaissent rien d’autre que Vim — un éditeur de texte qui fait pareil mais en beaucoup moins intuitif et facile à maitriser, allez comprendre !
1 De Mathieu Delestre -
En bon utilisateur de Mercurial au quotidien j’ai hâte de voir ce que tu va pouvoir écrire sur le sujet.
Vivement la suite ^^
Mais au fait pourquoi Mercurial et non Git (^^ mon choix est déjà fait mais j’aimerais bien savoir pourquoi le devteam dotclear à retenu HG)
2 De O-plus -
Comme d’hab, j’ai presque rien compris mais j’ai tout lu, M’sieur :-)
3 De Franck -
Mathieu le choix a été fait par ignorance. Je m’explique. Un des membres de l’équipe a proposé de basculer sur un système de gestion de version plus souple que Subversion (gestion des contributions externes, gestion de branches, …). Il a proposé Mercurial et l’utilisation des services de Bitbucket pour ce faire. Étant donné qu’il était le seul à connaître ce système, on lui a fait confiance et on a initié un test pour la sortie de la prochaine release à venir de Dotclear.
De cette expérience nous en tirerons alors quelques enseignements qui pourront le cas échéant nous inciter à continuer comme ça, à installer notre propre serveur Hg sur un de nos serveur ou à revenir sur l’ancien système Subversion. Ce n’est en tout cas pas encore le moment de faire ce choix, mais nous en reparlerons le moment venu.
Voilà pourquoi je serai bien incapable d’expliquer le choix effectué entre Git et Hg, ne connaissant ni l’un ni l’autre au moment du début de nos tests. Cela dit, l’initiateur de cette démarche passera peut-être dans le coin pour expliquer tout ça, qui sait ?
O-plus j’admire ton abnégation à vouloir lire jusqu’au bout :-)
4 De [SiMON] -
J’ai eu l’occasion d’expérimenter hg pour quelques contributions petites sur Clearbricks, et il est clair que c’est beaucoup plus simple que l’ancien système de contribution (envoi d’un patch, attente, etc.), et rien ne m’empêche, dans le cas où mes modifications seraient rejetées de l’édition originale, de continuer à faire avancer mon fork en y intégrant les modifications du projet parent.
Je ne suis pas du tout expert en systèmes de gestion des versions mais j’arrive à utiliser hg sans trop de problèmes, ce qui n’a pas été le cas, par exemple, avec svn quand j’avais tenté de l’utiliser (pour m’intégrer au mieux sur Google Code) il y a quelques année.
PS: Ça existe encore les blogs où l’on ne peut pas s’abonner aux commentaires :° ?
5 De Franck -
Personnellement j’ai trouvé Subversion plus simple d’accès que Mercurial. Question d’habitude probablement.
Pour le PS, il y a un fil RSS spécifique à ce billet ou le fil RSS général des commentaires du blog. N’est-ce pas suffisant ?
6 De mirovinben -
Voilà une démarche qu’elle est bonne… Excellente même ! Et sans Klingon dedans. Je souris d’aise. Cela me permettra de mieux comprendre une grande partie des échanges mail entre membres de l’équipe Dotclear (dont je suis le maillon faible). Échanges dont j’ai été le témoin déconcerté (souvent) et amusé (beaucoup).
Comme O-plus, j’ai tout lu.
J’attends avec impatience (et crainte pour mes derniers neurones en état) l’aspect “travail collaboratif” où chacun bidouille “sa” version dans son coin et met au pot ensuite.
7 De [SiMON] -
La logique “flux RSS” a ses limites je trouve. Si je dois m’abonner à chaque article que je commente, j’aurais bientôt plus de flux de commentaires que de flux de billets dans mon agrégateur. Les flux sont une merveilleuse invention quand il s’agit de suivre du contenu, beaucoup moins pour des commentaires amha. Mais ce n’est pas forcément le lieu pour un tel débat.
8 De Franck -
C’est vrai que ça peut devenir pénible pour un “gros” commentateur. Quand au lieu, ici est très bien, sinon où ?
9 De Dsls -
Matthieu, le choix de Hg vs git a été globalement arbitraire, les 2 outils se valent. Ce qui a orienté le choix vers Hg a été essentiellement sur le client windows (il y a encore des gens sous windows), qui est bien plus complexe et volumineux à installer pour git (besoin de msysgit+tortoisegit) que tortoiseHg qui est plus directement accessible.
10 De Lomalarch -
Moi qui ne suis pas moins faiblement maillonné que le camarade mirovinben, je vais tâcher de faire mon miel de tout ceci :-)