Ça faisait un moment que Mozilla cherchait à remplacer l'antique CVS. À ma connaissance, ça commence là, avec des ambitions modestes :
http://weblogs.mozillazine.org/roadmap/archives/2006/10/mozi(...)
We don't need "the best" or the "newest", but we do need better merging, branching, and renaming support.
Mais la liste des besoins s'est allongée au fur et à mesure des discussions :
http://wiki.mozilla.org/Version_Control_System_Requirements
Visiblement, l'avantage a vite tourné aux systèmes décentralisés (branches privées, commit et autres opérations hors-ligne, ...). Exit Subversion, donc.
Un autre critère discriminant : un bon support pour Windows. Bah oui, les logiciels Mozilla sont libres, mais la majorité de ses utilisateurs (je ne sais pas pour les développeurs) sont sous Windows. Le portage de Git n'est visiblement pas encore au point (mais il progresse...), ni celui de monotone.
Là, il ne restait plus que Bazaar et Mercurial en finale. Et là, malgré les efforts de l'équipe de Bazaar au niveau performances (depuis la version 0.9, les performances sont la priorité du développement de Bazaar, avec des gains d'un facteur deux au moins sur pas mal d'opérations), Mercurial sort grand vainqueur.
http://weblogs.mozillazine.org/preed/2007/04/version_control(...)
Plus généralement, en ce moment, il y a une grande diversité dans le monde des gestionnaires de version décentralisés, et ça évolue à toute allure. GNU Arch qui avait ouvert la voie est quasi-mort. Darcs, qui a apporté pleins d'idées nouvelles à la fois sur la théorie et sur l'interface utilisateur n'a pas (encore ?) réussi à atteindre des performances acceptables sur un très gros projet. J'avais pas mal misé sur Bazaar, mais les problèmes de performances n'ont pas l'air de se résoudre aussi bien que prévu, et la pérénnité me parait bien incertaine.
J'ai l'impression que Git et Mercurial sont les deux qui s'en sortent le mieux au moins sur des gros projets : Git satisfait la communauté des développeurs Linux pour laquelle il a été créé, et a convaincu par exemple X.org. Mercurial a OpenSolaris et maintenant Mozilla.
Journal Mozilla passe à Mercurial
15
avr.
2007
# Systèmes de gestion de version distribués
Posté par vieuxmk . Évalué à 9.
Il me semble que les problèmes de montée en charge de darcs viennent de son algo de gestion des conflits et de la forte complexité algorithmique (O(n^2) avec n le nombre de conflits si je me souviens bien) de ce dernier, pas d'une sous optimisation du code ou quoi que ce soit dans ce goût.
Ainsi que Xen[0], l'hyperviseur, autre gros projet libre.
Le programme Tailor[1], permet de passer d'un SGV (distribué ou non) à l'autre plus ou moins facilement.
Sinon, il y a eu une grosse série de billets concernant les systèmes de gestion de version distribués sur le blog[2] de John Goerzen, ou il a comparé notamment darcs, mercurial, bzr et git :
http://changelog.complete.org/posts/528-Whose-Distributed-VC(...)
http://changelog.complete.org/posts/588-Re-Examining-Darcs-M(...)
http://changelog.complete.org/posts/593-Mercurial-Git.html
http://changelog.complete.org/posts/594-More-on-Git,-Mercuri(...)
http://changelog.complete.org/posts/595-bzr,-again.html
http://changelog.complete.org/posts/596-Some-more-git,-mercu(...)
Pour résumer, darcs est excellent pour "micro"-gérer les patchs et "darcs send" n'a pas encore d'équivalent aussi confortable mais mercurial est clairement le meilleur et plus polyvalent à l'heure actuelle, sachant que git promet beaucoup aussi malgré son manque de doc et de prise en charge question célèbre-os-propriétaire©®. J'ai trouvé ses réflexions assez argumentées et les commentaires des supporters de l'une ou l'autre des solutions informatifs.
Mercurial serait-il en train de prendre la tête ?
[0] : http://xenbits.xensource.com/
[1] : http://progetti.arstecnica.it/tailor
[2] : http://changelog.complete.org
[^] # Re: Systèmes de gestion de version distribués
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
> de son algo de gestion des conflits
Tout à fait (enfin, pas seulement des conflits je crois. Du merge en général plutôt). Darcs repose sur une théorie différente des autres (en gros, l'algo de merge basic, c'est trouver l'ancetre commun des deux révisions à fusionner, puis un coup de diff3 dessus). C'est à la fois puissant et gourmand en ressources. Quand on tombe sur un cas où Darcs part en vrille, il faut attendre que l'auteur trouve une meilleure théorie :-\.
Mais en échange, Darcs est relativement imbattable pour la selection des patchs un par un. Grosso-modo, un projet est un « tas » de patchs, et c'est Darcs qui réordonne les patchs comme il faut pour minimiser les conflits.
# Flock
Posté par Erwan . Évalué à 5.
Plusieurs developpeurs (comme moi) utilisent git-svn : ca permet d'utiliser git pour se connecter a un serveur svn. Donc on a les avantages de git pour nous sans avoir a faire migrer tout le projet !
# Git
Posté par Xavier Maillard . Évalué à 8.
Darcs était mon chouchou car question prise en main et utilisation au jour le jour, c'était assez bleuffant. Seul (gros) bémol: c'est un gros veau ! :)
Bazar & co (tla, arch, ...) ben je n'ai jamais vraiment réussi à en disposer comme je le voulais. Trop compliqué même si les choses se sont améliorées sur la fin; malheureusement le mal était fait.
Mercurial, très bien, très rapide et facile à utiliser et à administrer. Malheureusement je suis arrivé à une période où l'API n'était pas stable et changeait sans cesse occasionnant des reconfigurations à tours de bras.
SVN, jamais pu piffrer le nom alors je n'ai même pas essayé :)
Il me restait donc Git et là, j'ai découvert un projet de très bonne facture et la liste de diffusion a fini par me persuader que le projet avançait dans la bonne direction. J'ai aussi pu constater *sur pièce* que ce Linus avait vraiment une aisance à "pisser du code" et à optimiser tout le code produit. J'aime particulièrement sa façon de faire bien que je n'apprécie pas forcément le Monsieur dans sa façon de parler aux autres. Question prise en main, Git se révèle assez simple pour peu qu'on ait pas trop pratiquer autre chose avant parce que certains concepts sont très destabilisant (le rebase par exemple qui est une sorte de merge mais en beaucoup plus puissant).
Autre point fort de Git, les nombreux outils (modes GNU Emacs, scripts d'exemple, documentations *très riches*, cas d'usages, et autres importateurs depuis d'autres SCM). Il est par exemple très simple de passer de CVS à Git, ou bien de faire la passerelle entre un Git et un SVN.
Bref, que ce soit un projet de 50 lignes ou de 50Klignes, je n'utilise plus que Git :)
P.S: j'ai essayé monotone & co mais je mise davantage sur un projet qui fait ses preuves au jour le jour avec la gestion du code source du noyau linux, c'est un bel exemple je trouve :)
# monotone
Posté par Vivi (site web personnel) . Évalué à 5.
euh, pour ce que j'en sais il n'y a pas de "portage" de monotone vers Win32 parce que le code est multi-plateforme dès le départ. Je l'utilise régulièrement sous Windows et ça marche plutôt bien.
[^] # Re: monotone
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
[^] # Re: monotone
Posté par Vivi (site web personnel) . Évalué à 2.
En fait il n'y a pas que des raisons techniques: il est également impliqué dans Mozilla et il n'avait donc pas trop envie de mélanger les deux (« If mtn lacks a feature, or is too slow, it's my fault and job to fix. »)
J'aime bien le paragraphe de conclusion de son message:
# point de vue utilisateur...
Posté par ploum (site web personnel, Mastodon) . Évalué à 7.
CVS était un peu rébarbatif, avec ses z3 et compagnies, svn est je trouve relativement simple et fonctionne bien dans mon cas : update, commit, branching, merge et je vais pas plus loin pour mon usage personnel.
Après, arrivent les darcs, git, mercurial, bzr, etc...
Et là, c'est l'horreur. Quand on a déjà eu du mal à se mettre à SVN, on voit un petit projet sympa, on se dit : "tiens, je vais jeter un oeil au code source", tout motivé et, Paf, il faut se taper l'apprentissage d'un nouveau système de gestions des sources, avec des nouvelles théories à bien comprendre, des trucs des machins !
Ajoutons à cela l'éclatement des systèmes de compilations (avec les autotools, les config à la va comme je te pousse) et, au final, on a peut-être un tas d'outil puissant mais avant même de voir la couleur d'un fichier source, il faut compter 2 jours de boulot non stop : juste pour pouvoir télécharger et compiler !
Certes, on ne le fait qu'une fois, mais dans mon cas ça m'a arrêter très très très souvent.
Sans compter que, si je passe 6 mois sans utiliser un système, je me souviens plus de rien (je crois que j'aurais beaucoup de mal à me mettre à CVS).
Je n'ai pas de solutions à apporter, mais je pense utile de signaler que toutes ces dispersions sont des freins, à mes yeux, à de nombreuses contributions, et que ce n'est pas à perdre de vue non plus. Les gestionnaires de sources, tout comme les gestionnaires de compilations et tout ça sont des "outils" et il faut faire attention quand la gestion d'un outil devient plus compliquée que la tâche à laquelle sert l'outil.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: point de vue utilisateur...
Posté par benja . Évalué à 3.
Qu'entends-tu par « utilisateur » ? Je suppose que c'est l'utilisateur (curieux, motivé et connaissant la programmation) d'un programme (et non d'un scm) qui désire améliorer son fonctionnement.
Je dirais que s'il ne veut pas utiliser les outils utilisé par les développeurs de ce logiciel et s'il ne veut pas courrir après les librairies de développement; il peut se contenter d'un apt-get source & build-dep. Pour faire une petite contribution ponctuelle, c'est amplement suffisant. Pour quelque chose d'encore plus trivial (qui ne nécessite pas de recompilation), il peut consulter le viewcvs et y télécharger directement le fichier qu'il désire modifier. Il fait un bête patch et l'envois. Un gros frein ?
Maintenant, si cet "utilisateur" décide de s'impliquer un peu plus dans ce projet, il n'aura de tout de façon pas d'autres choix que de se familiariser avec les outils utilisé. Généralement, les projets fournissent des indications succintes pour récupérer les sources et recompiler le logiciel. Il passe donc de ce statut d'« utilisateur » à celui de développeur. Et petit à petit, il comprend à quel point ce logiciel de gestion de source (distribué) est un gros coup d'accélérateur au développement du projet...
[^] # Re: point de vue utilisateur...
Posté par ploum (site web personnel, Mastodon) . Évalué à 3.
J'avoue que je n'ai pas le réflexe apt-get source, c'est en effet un intermédiaire bien pratique, j'essaierai d'y penser la prochaine fois.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: point de vue utilisateur...
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Par exemple, avec darcs :
$ darcs get http://ton.projet.com/
#hack hack hack
$ darcs record
#hack hack hack
$ darcs record
# allez, j'ai assez contribué pour cette fois.
$ darcs send
J'avais jamais utilisé Darcs avant, je l'ai utilisé pour contribuer à ion3, le plus long a été de tapper « aptitude install darcs ». T'as vu où une nouvelle théorie ? Et avec SVN, tu aurais fait comment ?
(pour être honnete, les autres systèmes ne sont pas tous aussi simples)
L'énorme intérêt de ces systèmes, c'est justement pour le contributeur occasionnel. Tu n'as pas besoin d'avoir de droits sur le repository principal pour contribuer dans des bonnes conditions. Un « get », « clone » ou « branch » (selon l'outil) et tu es pret à contribuer, à faire une succession de patchs, autant de commit intermédiaires que tu veux, ...
Avec un outil centralisé, tu as le choix :
* Demander à l'admin d'avoir les droits pour commiter sur le SVN du projet. Si c'est pour une contribution de <100 lignes, je devine comment tu seras reçu.
* Oublier la commande « commit », oublier les branches, oublier qu'un gestionnaire de version sait faire autre chose que « diff » et « update ». Et si tu veux envoyer deux patchs séparés qui dépendent l'un de l'autre, je te souhaite bien du courrage.
Après, personnellement, je trouve qu'il y a trop de projets différents. Mais c'est la diversité qui a apporté des idées. À mon avis, il y a quelques grands qui vont émerger, et les autres qui resteront marginaux. Pour l'instant, les faits ont l'air de mettre Git et Mercurial en avant. On verra ce que l'avenir nous réserve.
[^] # Re: point de vue utilisateur...
Posté par Xavier Maillard . Évalué à 3.
Je contribue à pas mal de projets qui utilisent indifféremment darcs, git, svn, CVS, ... C'est leur choix et de mon côté je stock mes devs dans Git. Le seul cas un peu emmerdant est CVS qui ne dispose pas d'un mode "send patch" et donc pour informer de modifications en upstream, c'esst galère.
Le truc génial des DSCM c'est justement le "D". Plus besoin de demander pour contribuer/envoyer un patch. Tu fais, tu expliques et tu proposes aux personnes (upstream ou autres) de venir piocher. Les meilleurs DSCM proposent l'envoient de patchs par mail, c'est top.
Je passe sur les cherry-pick, rebase et branching.
Concernant la "sélection naturelle" des DSCM, je suis du même avis que Matthieu. Les meilleurs resteront pour le reste, on verra des rapprochements entre projets. Le concept de DSCM est relativement jeune et a encore beaucoup à démontrer mais sa percée est vraiment spectaculaire.
[^] # Re: point de vue utilisateur...
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 2.
Dans mon idée, les DSCM sont un outil FORMIDABLE (oui je le crie) pour les bidouilleurs du dimanche, qui bricolent plein de projets et (du coup) ne feront que de rares contributions. Dans ce cas, il n'est pas vraiment utile d'avoir un accès en écriture au dépot du projet. Il est bien plus efficace de soumettre ses modifications occasionnelles par patch.
Dans cette optique, je pense que l'outil qui restera sera celui qui offre le plus de "connectivité" avec les autres systèmes. En effet, ce n'est pas très productif de devoir sans cesse apprendre un nouvel outil pour récupérer les modifs des copains et calculer ses propres patches. Ce boulot doit être fait par l'outil DSCM. C'est à lui de savoir communiquer avec les autres, pas à l'utilisateur. Ainsi, le petit contributeur du dimanche peut rester productif car il manipule toujours le même outil (celui de son choix) même s'il participe à différents projets utilisant différents types de dépots.
Dans ce domaine, Git est plutôt bien founi il me semble. J'utilise Git en frontend SVN et ça fonctionne du tonnerre. Pour Git avec CVS, j'ai l'impression que c'est un peu plus laborieux. Il faudrait que les outils évoluent pour un meilleure prise en charge. En ce qui concerne Git et les autres (Bzr, mercurial, monotone...) je ne sais pas, mais il me semble avoir vu passer des trucs sur la mailing-liste.
[^] # Re: point de vue utilisateur...
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 1.
- la multiplicité des systèmes de gestion de version
- la difficulté à contribuer
Dans le second cas, je pense que c'est inévitable. Quoi qu'on veuille en penser, la programmation n'est pas "triviale" (les langages, les bibliotèques, les outils support...). Il y a forcément des tas de machin chose à régler avant de pouvoir générer un produit. Je ne parle même pas de la mise en place d'un envirronnement de test de ses modifs. Mais cela est inévitable. Je ne vois pas comment on peut éviter ces "inconvénients".
Concernant le premier point, les systèmes de gestion de version distribué peuvent justement aider l'utilisateur à n'avoir qu'un seul outil, qui se charge alors de communiquer avec les dépots, quelque soient leurs types (cf. mon autre post).
Par contre, c'est un peu fort de dire que les systèmes de gestion de version sont un frein au fait de contribuer du code. Au contraire, c'est grâce à eux que l'on peut travailler à plusieurs sans perdre inutilement du temps (écrasement des modifs du copain entre autre).
[^] # Re: point de vue utilisateur...
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
J'ai dit :
"la multiplicité des systèmes de gestion de version peut être un frein au fait de contribuer du code"
C'est très différent. Perso, j'ai un exemple concret le jour où un pote a voulu me montrer un projet sur lequel il travaillait et que j'étais curieux de voir. Il a commencé par me dire "bon, tu installes darcs, puis tu télécharges la source avec darcs". Comme je ne connaissais pas darcs mais qu'à l'époque j'avais déjà du mal à me mettre à svn, j'ai laissé tombé.
Clairement, j'avais pas une motivation de feu, mais ça m'a arrêté dès le début et je trouve ça dommage.
Ceci dit, je ne réalisais pas plein de choses concernant GIT et je me dis qu'utiliser GIT, et uniquement GIT, en interface avec tous les autres serait peut-être en effet une excellente solution. (bref, merci pour tous les messages)
Mes livres CC By-SA : https://ploum.net/livres.html
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.