La conférence commencera à 19h30 le jeudi 10 novembre, elle se tiendra à l'endroit suivant :
Relais Ménilmontant
85bis rue de ménilmontant
75020 Paris Grâce entre autres à l'hébergeur SourceForge, l'utilisation de systèmes de gestion de versions (VCS, Version Control System, également appelés SCM pour Source Code Management) en réseau s'est largement répandue et ces systèmes sont désormais un des principaux outils de travail collaboratif. Fini, le travail solitaire du programmeur génial, dont le monde ne voyait rien avant la "release".
Plus faciles d'utilisation et plus répandus, ces VCS sont utilisés par les développeurs bien sûr, mais aussi par les webmestres pour gérer les fichiers qui composent le site Web, par les auteurs de documentation ou de support de cours pour gérer leurs documents, articles ou exposés, etc.
Pendant très longtemps, l'unique logiciel sérieux de gestion de versions était CVS. Il reste aujourd'hui la référence. Mais maintenant que le vénérable CVS atteint sérieusement ses limites et que la créativité bouillonne dans ce domaine, après dix ans de monopole absolu de CVS, on va s'intéresser à la concurrence.
CVS souffre en effet de plusieurs limites : les "commits" ne sont pas atomiques (en cas de disque plein, par exemple, on ne commite qu'une partie des fichiers), les répertoires et les méta-données (le fait qu'un fichier soit exécutable, par exemple) ne sont pas versionnés, le travail sur du code tiers, développé en amont, est très pénible (l'outil de CVS pour ce travail, les branches, étant lent et difficile d'usage). Enfin, le code n'est plus du tout maintenu.
Pour succéder à CVS, il existe deux sortes de VCS, centralisés ou décentralisés. Tous ont en commun de ne plus travailler par fichier, comme CVS, mais par "changeset" ou "patch", un ensemble de changement sur plusieurs fichiers.
Dans les systèmes centralisés, il y a un dépôt de référence et les utilisateurs lisent et écrivent uniquement dans ce dépôt. CVS est l'archétype de ces VCS. Mais désormais, sur ce créneau, il cède du terrain à Subversion. Ce dernier, baptisé "CVS++", tente de faire "CVS sans les problèmes". Par exemple, une petite révolution : on peut enfin renommer un fichier. Ou bien on peut enfin "versionner" les meta-données.
Les concepts étant les mêmes, les simples utilisateurs passent de CVS à Subversion en cinq minutes, d'autant plus que les commandes sont identiques. Pour l'administrateur, c'est plus difficile, car le changement est plus profond. Le format du dépôt est complètement différent (il en existe au moins deux, avec DB et avec des fichiers plats). La configuration d'un serveur réserve quelques pièges, on peut utiliser Apache 2 et WebDAV ou bien le plus simple svnserve.
Dans les systèmes décentralisés, le sujet chaud du moment, on essaie de mieux coller au mode de développement en réseau si fréquent dans le logiciel libre.
Dans ces VCS, il n'y a plus de dépôt de référence. Plusieurs dépôts coexistent et on peut lire et écrire dans celui de son choix.
Cela met fin au dépôt central sacré avec ses "commiteurs" privilégiés qui regardent les autres de haut. Le fait d'accorder ou de refuser le droit de "commiter" entraîne souvent des crises qui sont désormais inutiles.
La décentralisation permet plus facilement de suivre un logiciel amont, auquel on ajoute quelques patches qui ne seront pas forcément intégrés. Les VCS décentralisés dédramatisent ainsi le "fork", la scission, qui a secoué tant de projets de logiciel libre, en le rendant moins radical et moins définitif.
Elle permet enfin, ce qui est important compte tenu de l'explosion de l'utilisation des portables un travail en déconnecté (le portable contient un vrai dépôt). Les principaux représentant de la catégorie des VCS décentralisés sont Mercurial, SVK, monotone, git et enfin darcs, qui est le plus simple à utiliser.
Arch et sa mise en oeuvre la plus connue, tla, est l'ancêtre des VCS décentralisés. tla est très complexe à utiliser, mais il a néanmoins débayé le terrain et introduit le concept de décentralisation auprès de beaucoup d'utilisateurs, concurrençant sérieusement Subversion.
Plus récent, darcs est à la fois bien plus simple (comme CVS, on peut s'y mettre en quelques minutes) et plus matheux avec sa fameuse "théorie des patches" qui tente de donner un cadre théorique solide à la gestion des conflits entre dépôts décentralisés qu'on essaie de synchroniser. L'algorithmique mise en jeu par les VCS décentralisés est en effet bien plus complexe.
C'est darcs qui pousse le plus loin la logique des VCS décentralisés : toute copie de travail est un dépôt de plein droit. L'équivalent des branches de CVS, par exemple, est juste un autre dépôt.
Contrairement à Subversion, darcs n'est pas encore utilisé en production pour des gros projets mais il est très prometteur.
Aller plus loin
- Parinux (8 clics)
- Plan d'accès (2 clics)
- Les gestionnaires de version sur Wikipédia (3 clics)
# Y'a aussi Bazaar 2
Posté par Matthieu Moy (site web personnel) . Évalué à 7.
http://bazaar.canonical.com/Bzr
Il n'est pas encore tout à fait fini, mais il est proche de Darcs au niveau de l'utilisation (et en particulier de la simplicité d'utilisation).
Une de ses grande forces, c'est son système de plugins (écrits en Python). Il permet d'avoir une base de code et un ensemble de commands pas trop gros, mais en permettant aux utilisateurs avancés de rajouter ce dont ils ont besoin en installant un plugin.
Le projet est jeune, mais il y a une communauté très active derrière (une bonne partie des anciens contributeurs de GNU Arch, et plusieurs salariés Canonical à plein temps), il avance vraiment très vite.
J'en profite pour faire de la pub pour le package Emacs qui permet d'utiliser bzr depuis Emacs (loin d'être fini, mais ça commence à marcher pas trop mal pour visualiser des diffs et commiter), successeur de Xtla pour ceux qui connaissent (il supportera aussi mercurial dans un futur proche si tout va bien):
http://wiki.gnuarch.org/xtla#DVC
[^] # Re: Y'a aussi Bazaar 2
Posté par ArBaDaCarBa . Évalué à 3.
http://bazaar.canonical.com/FrontPage
Perso, j'ai plus l'impression que bzr est un remplaçant de RCS (l'ancètre de CVS ?).
[^] # Re: Y'a aussi Bazaar 2
Posté par Matthieu Moy (site web personnel) . Évalué à 5.
Tu peux développer ?
J'ai jamais utilisé RCS, mais je crois pas qu'on pouvais faire de merge d'un repository à l'autre, qu'il y avait un support http/sftp, un historique des merge, un opérateur de merge basé sur les "weaves" (comment on traduit ça ?), une selection des patchs section par section, une gestion des renommages correcte, des commit atomics ...
Bref, à part le fait que l'archive est dans le répertoire de travail, qu'est-ce qu'il y a comme point commun entre RCS et bzr ?
[^] # Re: Y'a aussi Bazaar 2
Posté par Pascal Terjan (site web personnel) . Évalué à 8.
le R /o\
[^] # Re: Y'a aussi Bazaar 2
Posté par ArBaDaCarBa . Évalué à 2.
[^] # Re: Y'a aussi Bazaar 2
Posté par Matthieu Moy (site web personnel) . Évalué à 5.
Aujourd'hui, je peux faire par exemple:
$ bzr branch http://bazaar-ng.org/bzr/bzr.dev
$ cd bzr.dev
<hack hack hack>
$ bzr commit -m "killer feature"
# Récupérer les modifs de bzr.dev depuis le branch
$ bzr merge
$ bzr commit
# publier mes changements
$ bzr push sftp://shells.sourceforge.net/bla-bla-bla
$ echo "tu peux merger" | mail auteur-de-bzr
Plus tard, il y aura a priori un "brz send" comme le fameux "darcs send".
En ce moment, Canonical est en train de faire sa migration en interne. Pour une idée de la quantité d'archives gérées, voir par exemple http://bazaar.ubuntu.com/ (pour l'instant, ces archives utilisent bazaar 1.x). La notion de gestion de version décentralisée est au coeur de la politique de Canonical et des idées de Mark Shuttleworth : le but est de favoriser la coopération entre les distributions. Quand ubuntu modifie un logiciel pour sa distrib, les modifications sont publiées en utilisant un gestionnaire de versions, c'est à dire proprement, avec un message de commit pour chaque modif, éventuellement plusieurs branches, et pas juste un gros patch. Bref, tout ça pour dire qu'il y a des exigences bien plus importantes que RCS derrière bzr ;-).
Je trouve Bazaar 1 déjà très bon (mais trop compliqué pour les débutants, et pas assez rapide), tu peux te douter que Bazaar 2 a pour ambition d'être mieux.
(ceci dit, le fait que bzr soit bien ne fait pas des autres des mauvais gestionnaires de versions)
[^] # Re: Y'a aussi Bazaar 2
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 8.
Il existe actuellement au moins une douzaine de VCS libres décentralisés. Monotone, darcs, tla 2, Bazaar-NG, Codeville, ArX, Fascist, svk, Mercurial, git/cogito... et j'en oublie.
Le but de mon exposé n'était pas de faire une présentation de tous ces logiciels, d'autant plus que la majorité aura disparu dans deux ans (comme tla qui était super à la mode il y a deux ans et déjà en cours d'oubli).
Je voulais au contraire sensibiliser les utilisateurs de CVS à l'existence d'autres outils, d'autres solutions. Ce n'est pas facile, surtout que le concept même de VCS décentralisé suscite des réactions aussi vigoureuses que le concept d'édition sans verrou de CVS il y a quinze ans.
Donc, vous comprendrez que je ne tienne pas compte des messages du genre "Ouais, XYZ 1.0, C top k00l" :-) Ils ne sont pas du genre à rassurer ceux qui craignent de quitter CVS.
[^] # Re: Y'a aussi Bazaar 2
Posté par Matthieu Moy (site web personnel) . Évalué à -1.
Plus sérieusement, évidemment que tu ne peux pas faire une présentation qui parle de tout les gestionnaires de versions, mais il me semble que bzr mérite d'être au moins mentionné, il a beaucoup de potentiel et pourrait être un de ceux qui ne disparaitront pas dans moins de deux ans justement.
[^] # Re: Y'a aussi Bazaar 2
Posté par tinodeleste . Évalué à 3.
Il est bien là le problème. On assiste à un début d'utilisation d'une multitude de systèmes, surtout en décentralisé, et on a aucune idée de ce qu'il en restera dans deux ans.
Ils ont beau, pour certains, être 'facile' (j'ai du mal a mettre gnu arch et facile dans la même phrase, mais bon) à apprendre à utiliser, il n'en reste pas moins que maîtriser les commandes de 3-4 outils comme ca conduit à des erreurs (comme des svn delete qui effacent le vrai fichier en plus de celui sur le dépôt, au contraire de ce que faisait cvs...)
Enfin bon, à dans deux ans pour savoir s'il y aura eu un peu d'écrémage...
[^] # Re: Y'a aussi Bazaar 2
Posté par Ramso . Évalué à 2.
# hg mercurial
Posté par schyzomarijks . Évalué à 4.
un article détaillé : http://lwn.net/Articles/151624/
et une page du wiki http://www.selenic.com/mercurial/wiki/index.cgi/ConvertingRe(...) pour convertir un dépôt cvs en hg.
Ca gère des gros projets ? oui, un dépot suit la branche du kernel linux est dispo sur kernel.org http://www.kernel.org/hg/linux-2.6/
Moi, j'adooore.
# Inscription
Posté par Pierrick Le Gall (site web personnel) . Évalué à 1.
Bref, on peut venir sans s'être inscrit ? je suis très intéressé.
[1] http://parinux.org/activites/conf
[^] # Re: Inscription
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 2.
http://www.parinux.org/news/news-req.html?news=245
et je suppose (mais je ne suis pas à Parinux) qu'on peut venir informellement.
[^] # Re: Inscription
Posté par Paul Marques Mota . Évalué à 1.
# Personnellement
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 3.
Par contre il est de plus en plus important d'avoir aussi un outil de gestion autour de celui d'historique, et pour le moment à part trac je ne trouve rien. Un truc qui gère les tickets, etc.
Pour le moment mes configs c'est :
- subversion avec apache2/https
- le post-commit activé avec un mail pour tous les commits sur des listes privées accessibles aux développeurs
- un trac pour gérer les tickets, avoir le repo accessible sur le web. Mais ce n'est pas idéal, trac necessite d'être sur la même machine que le repo svn, et la gestion des droits est assez chiante à mon goût.
Et vous vous utilisez quoi pour la gestion de projets ?
(C'est chiant que la conf soit dans le 20eme loin de chez moi, pour une fois que ça m'intéresse :)
[^] # Re: Personnellement
Posté par wilk . Évalué à 2.
[^] # Re: Personnellement
Posté par kang . Évalué à 2.
on utilise svn + svk (http://svk.elixus.org/) ici
pas de https, tout passe via ssh.. svnserve tourne pour les access anonymous..
et viewsvn pour la vue online sans acces au repo direct.. par contre c'est lent, forcement, ca passe via svnserve.
Ensuite un ptit script pour integrer les commits au bugtracker et pi vala (mantis)
[^] # Re: Personnellement
Posté par Hubert . Évalué à 3.
L'approche de Trac me plait aussi sur le fond et pas sur la forme. Je me laisserais bien aller à lancer un projet qui constituerait une série d'extensions à un Wiki quelconque (au hasard MoinMoin) qui ferait l'interaction entre lesdits tickets, le VCS et les développeurs.
L'idée est simple : un projet = des développeurs + un référentiel de source + des tickets catégorisés. Chaque page dédiée aux tickets alimente un flux RSS. Idem pour les commits et tout autre événement à rattacher au projet. Chaque développeur a sa vue, avec laquelle il peut se brancher sur les flux qui l'intéressent. Pour le reste, c'est un wiki ; donc la doc, les débats architecturaux et autres peuvent se réaliser dans l'outil en toute liberté. Notamment, chaque page peut référencer très simplement un ticket, un bout de code du projet...
Il y a d'ailleurs l'outil Confluence d'Atlassian qui est basé sur cette idée. C'est hyper séduisant mais c'est ni libre, ni open source. Et puis, il faut s'équiper d'un serveur d'appli Java...
Et vous ? Vous avez entendu parler de tels projets ?
[^] # Re: Personnellement
Posté par golum . Évalué à 4.
http://scarab.tigris.org/
[^] # Re: Personnellement
Posté par Hubert . Évalué à 2.
Je regrette toujours cependant de devoir passer par une appli web Java. Quant à l'intégration avec SVN, elle me semble encore bien légère :
http://www.wever.org/java/space/java/Integrating+Subversion+(...)
Notamment, rattacher les users du VCS à celui du bugtracker ne semble pas si trivial, et pourtant...
Je regrette aussi que l'édition de bug ne profite pas de la simplicité et de la puissance qu'offre un wiki.
En fait, je suis peut être un doux rêveur, mais je pense qu'un bon wiki bien outillé pourrait faire un parfait bugtracker[1]. Le problème majeur à résoudre à mon sens étant : la recherche de mots clés dans les bugs.
[1] Soyons modeste tout de même : un parfait bug tracker pour PMP (Petits et Moyens Projets)
[^] # Re: Personnellement
Posté par golum . Évalué à 2.
Tu regrettes que ce soit une appli Web Java et que ce ne soit pas un wiki.
Mais tous les wiki que je connais sont des applis Web.
C'est le coté java qui te gêne ou le coté client léger ?
[^] # Re: Personnellement
Posté par Hubert . Évalué à 1.
Allez t'as raison ! Je retire ce point-là. M'enfin, il nous en reste quelques uns tout de même :-)
# Diverses remarques
Posté par Boa Treize (site web personnel) . Évalué à 3.
C'est également le cas pour git et mercurial, qui ont repris cette excellente idée. Par ailleurs, comme Darcs, ils sont très légers à installer et à mettre en place, une autre évolution positive.
Pendant très longtemps, l'unique logiciel sérieux de gestion de versions était CVS.
... dans le monde open-source. L'article ne le dit pas tellement c'est évident, mais il y a tout un tas de VCS propriétaires à côté desquels l'offre open-source à longtemps fait pâle figure. Bien sûr, il faut payer et supporter toutes les irritations d'un monde clos.
[^] # Re: Diverses remarques
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 2.
> longtemps fait pâle figure.
Ah non merci, des outils dangereux (perte de données), non automatisables, stockant les données sous leur format (donc quand le serveur de licence est en panne, aucun moyen de les récupérer), des outils dont le seul avantage était le cliquodrome fourni avec ?
Le domaine des VCS est un domaine où l'avantage des logiciels libres est net.
[^] # Re: Diverses remarques
Posté par Matthieu Moy (site web personnel) . Évalué à 6.
Mouais. Va expliquer ça à Torvalds ...
L'avantage est probablement en train de revenir aux logiciels libres, mais prétendre qu'il y a quelques années (ou hors CVS, point de salut), le libre devançait le propriétaire (on ne citera que ClearCase et BitKeeper), c'est un peu fort de café.
# (très) petit compte rendu
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 4.
Je ne ferais pas l'affront à Stephane Bortzmeyer de résumer sa conférence car il l'a très bien fait dans cette dépêche, et ses slides, sous GFDL avec les notes du présentateur seront disponibles en ligne dans 3 à 4 semaines.
La présentation s'est découpée en trois parties:
- présentation et rapide historique des VCS
- exemple de vcs centralisé avec Subversion
- la nouvelle génération de vcs décentralisés avec darcs et git/cogito
La conférence s'est terminé sur un petit débat d'une dizaine de minutes sur la gestion des merges et l'aide (technique et sémantique) que les outils pouvait ou pourraient apporter aux développeurs.
Merci et bravo à Stéphane car tenir près de 2h, et répondre ensuite à toutes les questions de manière tout aussi compréhensible, ce n'est vraiment pas facile. J'en suis ressortit avec les idées plus claires.
[^] # Re: (très) petit compte rendu
Posté par Pierrick Le Gall (site web personnel) . Évalué à 2.
Les concepts de VCS décentralisé ne sont de toute façon pas encore abordable pour la majorité des développeurs. On verra dans quelques années si l'idée a fait son chemin :-) je l'espère.
[^] # Re: (très) petit compte rendu
Posté par wilk . Évalué à 2.
Je me souviens que lorsque tuxfamily a connu des problèmes il y a eu un engouement énorme pour les décentralisés, les mailings-lists de ces gestionaires ont connu immédiatement un afflux francophone !
Souvent on trouve les systèmes décentralisés trop complexes parcequ'on regarde les fonctions avancées, mais il est tout à fait possible de se contenter des commandes de bases, et dans ce cas c'est bien plus simple que cvs ou svn.
[^] # Re: (très) petit compte rendu
Posté par liberforce (site web personnel) . Évalué à 2.
Y avait il des visuels (présentations ooo ou autre ?) qui seraient diffusables, ou des liens ?
[^] # Re: (très) petit compte rendu
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 3.
Elle seront disponibles au moins sur le site de Parinux.
[^] # Re: (très) petit compte rendu
Posté par liberforce (site web personnel) . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.