Articles précédents : Logiciel
- [12] Sortie de TrueCombat: Elite 0.49
- [12] ejabberd 1.1.2 est disponible
- [25] Sortie de Teardrop 0.9 : méta-moteur de recherche
- [34] Jeu de stratégie GPL : TA3D
- [175] Nuxeo CPS tournera sous Java
- [20] Hyla 0.7.0
- [9] Men are ants
- [29] Sylpheed-Claws 2.5.0 est sorti !
- [84] OpenOffice.org prend désormais en compte la nouvelle orthographe française
- [34] Salto Consulting se met à l'Open Source
Liens connexes
- Site officiel de Bazaar (français) (294 hits)
- Site officiel de Bazaar (64 hits)
- Performances de bazaar (64 hits)
- Comparaison des logiciels de gestion de version (181 hits)
- DLFP : Des nouvelles des gestionnaires de versions GNU Arch et Bazaar (43 hits)
Dépêche modérée par
Dépêche éditée par
Logiciel : bzr 0.11 vient de sortir
Posté par TeXitoi (Jabber id, page perso, ). Modéré le 02 octobre 2006.
Les principales nouveautés de cette version sont l'apparition d'un serveur dédié (pour le moment uniquement à travers ssh) ainsi que des améliorations de performances.
![[fr]](../../../images/fr.png)
Site officiel de Bazaar (français) (294 hits)![[en]](../../../images/en.png)
Site officiel de Bazaar (64 hits)-
Performances de bazaar (64 hits)
-
Comparaison des logiciels de gestion de version (181 hits)
-
DLFP : Des nouvelles des gestionnaires de versions GNU Arch et Bazaar (43 hits)
> Lire la dépêche (39 commentaires, moyenne: 3,5).
Ce projet fut initié par Canonical. bzr est capable de s'auto-gérer depuis mars 2005. Basée initialement sur les idées de GNU Arch, ses développeurs tentent de réunir tout les points forts des différents logiciels de ce type dans un même programme.
À ses débuts, le principal reproche fait à bzr était ses faibles performances. Depuis la version 0.7, les performances ont été très fortement améliorées, pour le rendre aujourd'hui utilisable sur de gros projets.
bzr est le logiciel de gestion de versions décentralisé libre regroupant le plus de fonctionnalités. Notons notamment le support complet officiel sous Windows, le support d'un système de greffons ainsi qu'une vraie gestion des renommages de fichiers.
Performances...
Ca faisait longtemps que j'avais pas retesté bzr alors vu qu'ils font beaucoup de buzz par rapport aux performances j'ai fait un petit test (hg est également écrit en python):
cache chaud
nombres de fichiers: ~20k (kernel linux)
taille: 280M
temps pour ajouter + commiter les fichiers:
bzr: 5min 1s
hg: 1min 56s
temps pour faire un status:
bzr: 6.6s
hg: 1.3s
taille du repo:
bzr: 232M
hg: 126M
bzr est le logiciel de gestion de versions décentralisé libre regroupant le plus de fonctionnalités.
Ca me semble quand même un peu exagéré, et pas forcement respectueux des devs des autres systèmes (darcs, monotone, git, mercurial, ...)
-
[^]Re: Performances...
Posté par Philippe Fremy (page perso, ) le 03/10/2006 à 06:33. (lien). Évalué à 3.Ca, c'est du cassage en regle !
En dehors de ses performances, est-ce que bazaar sait faire des choses mieux que les autres. Quid de hg, j'avais jamais entendu parle. C'est stable ?-
[^]Re: Performances...
Posté par TeXitoi (Jabber id, page perso, ) le 03/10/2006 à 07:02. (lien). Évalué à 2.Voir le lien "Comparaison des logiciels de gestion de version" au dessus (hébergé par bazaar, avec un lien vers le comparatif de wikipedia).
hg = mercurial. Mercurial est inspiré de git. Son but premier est la rapidité. Il est stable et utilisé par quelques gros projets (OpenSolaris notamment).-
[^]Re: Performances...
Posté par ribwund () le 03/10/2006 à 07:26. (lien). Évalué à 4.Mercurial est inspiré de git.
Je sais pas d'ou vient cette idée mais git et mercurial ont été commencé le même jour d'ailleurs mercurial a été utilisable avant git (cf les archives du kernel). Si un SCM a vaguement inspiré git et mercurial c'est monotone (la façon dont sont utilisés les hash).
-
-
[^]Re: Performances...
Posté par Matthieu Moy (page perso, ) le 03/10/2006 à 07:07. (lien). Évalué à 5.« Mieux », c'est toujours une question de point de vue.
Le lien sur la comparaison dans la dépêche donne une idée. Pour moi, les killer-features de bzr, c'est la possibilité d'héberger des projets sur à peu près n'importe quel serveur web (il suffit d'avoir ftp/sftp et http, rien d'autre à installer sur le serveur), le fait qu'on peut choisir entre « 1 branche = une copie de travail » à la darcs/hg/git et « 1 branche peut avoir plusieurs checkouts » (comme avec le bon vieux CVS/svn/...).
La gestion des renomages est vraiment bonne. À l'ajout d'un fichier ou d'un répertoire, un identifiant unique est créé (comme dans GNU Arch), et le nom du fichier est une information comme une autre après. En comparaison, Mercurial ne sait pas maintenir une branche avec un fichier renommé, et ne gère pas, par exemple, un ajout de fichier dans un répertoire renommé.
Mais on peut sûrement trouver des cas où c'est Mercurial ou git qui aurait l'avantage. Darcs est excellent pour la gestion des patch individuelle (cherrypicking) par exemple.
Après, c'est clair qu'ils se sont concentrés sur les fonctionalités et non sur les perfs. Aujourd'hui, c'est encore lent en comparaison avec hg ou git, mais c'est déjà rapide comme l'éclair comparé à ce qu'on avait il y a même pas 6 mois. Il y a encore du boulot d'optimisation sur la todolist (le « smart server » n'est qu'une ébauche pas du tout optimisée, tout est encore en python contrairement à Mercurial qui a déjà les parties critiques en performances optimisées en C, ...). La question est plus de savoir où s'arrêteront les gains de performance, il y a de bonnes chances que ça se joue à quelques dizaines de pourcent près à terme (Darcs restera sans doute à la traine, puisqu'il est basé sur des concepts qui le rendent intrinsèquement plus lent, et déjà bien optimisé aujourd'hui).-
[^]Re: Performances...
Posté par ribwund () le 03/10/2006 à 07:47. (lien). Évalué à 4.En comparaison, Mercurial ne sait pas maintenir une branche avec un fichier renommé, et ne gère pas, par exemple, un ajout de fichier dans un répertoire renommé.
ETA pour la feature dans mercurial: quelques semaines. En effet Matt Mackall (le créateur du projet) est payé par Sun pour l'implementer et il a une deadline.
Après, c'est clair qu'ils se sont concentrés sur les fonctionalités et non sur les perfs.
Pour moi ce qui ressortait de la discussion au sprint de Londres, c'est qu'ils ont fait des choix qui limiteront forcement la performance (notamment le choix d'un identifiant unique pour les fichiers) et que pour arriver au niveau de hg/git, bzr devra passer par (encore) un changement de format du repository.
tout est encore en python contrairement à Mercurial qui a déjà les parties critiques en performances optimisées en C, ...).
Une seule chose a été optimisé (et ca a été fait dès le début du projet) c'est les méthodes pour patcher/differ qui sont forcement critique. Ca semble la première chose à optimiser et je me demande pourquoi bzr ne le fait pas (le reste n'est pas encore optimiser pour que ce soit critique ?)
La question est plus de savoir où s'arrêteront les gains de performance, il y a de bonnes chances que ça se joue à quelques dizaines de pourcent près à terme (Darcs restera sans doute à la traine, puisqu'il est basé sur des concepts qui le rendent intrinsèquement plus lent, et déjà bien optimisé aujourd'hui).
Et si bzr était aussi intrinsequement plus lent ?
-
-
[^]Re: Performances...
Posté par gS () le 03/10/2006 à 07:18. (lien). Évalué à 3.Concernant bazaar-ng, noun l'utilisons dans ma boite depuis 1 an. Les perfs s'améliorent de version en version et les plugins s'étoffent.
Pour le moment notre code ne contient que environ 80K lignes de code, mais ca grossit relativement vite ( la précédente version de notre soft toujours géré sous CVS a à peu pres 380K lignes ). Nous prévoyons que la nouvelle version sera plus conséquente que la précédente et pour le moment, nous n'envisageons pas de passer à autre chose que bazaar-ng.
Les perfs au commit/update ne sont pas vraiment un problème (pour nous, en tout cas), je ne pense pas que ca soit la meilleur façon de juger ce type d'outil. (a moins de faire un unpdate toute les 20 minutes :)
La fonctionnalité que j'appécie le plus sont les bound branches. Elles permettent d'émuler un fonctionnement centralisé ou chaque commit se fait simultanément sur le repository central et localement, on utilise que les commande commit/update. C'est tres pratique. Quand on le souhaite,on peu passer en mode décentralisé et se synchroniser avec la source que l'on veut ou bosser uniquement en local puis repasser en bound sur le serveur central avec une commande tres simple.
Les explications de James Blackwell sur le sujet (un des gars qui fait du support et aide les débutants) m'on vraiment bien aidé.
a++
Guillaume.-
[^]Re: Performances...
Posté par golum () le 03/10/2006 à 08:33. (lien). Évalué à 5."Les explications de James Blackwell sur le sujet (un des gars qui fait du support et aide les débutants) m'on vraiment bien aidé."
Un ptit lien pour que tout le monde en profite ?-
[^]Re: Performances...
Posté par gS () le 03/10/2006 à 14:57. (lien). Évalué à 5.C'est la: http://jblack.linuxguru.net/node/46
a++
-
-
[^]Re: Performances...
Posté par vrm (page perso, ) le 03/10/2006 à 08:40. (lien). Évalué à 1.juste par curiositée, vous êtes combien de développeur à l'utiliser sur un même projet ?
-
[^]Re: Performances...
-
-
-
[^]Re: Performances...
Posté par golum () le 03/10/2006 à 09:00. (lien). Évalué à 5.bzr tente de supporter pleinement le modèlé distribué et le modèle centralisé.
Dans l'approche centralisée avec bzr tu peux travailler en concurrence d'accès sur une branche hebergée sur un repository partagé.
A chaque fois que tu commites tu le fais à la fois dans ton archive locale et dans l'archive centrale.
Il en résulte une certaine complexité dans l'utilisation de l'outil comme tu pourras t'en apercevoir dans le lien suivant mais la possibilité existe
http://bazaar-vcs.org/SharedRepositoryTutorial
Hg ne se concentre que sur le modèle distribué. (Un repository par développeur et chaque utilisateur récupère les modifs des autres et les intègre dans sa branche.)
Il a effectivement été retenu par l'équipe d'OpenSolaris qui fournit un dossier de choix assez approfondi
http://www.opensolaris.org/os/community/tools/scm/;jsessioni(...)
-
[^]Re: Performances...
Posté par wilk (Jabber id, page perso, ) le 04/10/2006 à 16:42. (lien). Évalué à 3.Vu l'activité impressionante du développement actuel de bazaar, il est vraiment trop tôt pour mesurer quoi que ce soit ! Ceci dit ça a toujours été très stable depuis le début.
-
-
[^]Re: Performances...
Posté par TeXitoi (Jabber id, page perso, ) le 03/10/2006 à 06:58. (lien). Évalué à 1.hg reste plus performant, c'est sur. D'ailleur, c'est le but premier de hg, d'être performant. Il n'empêche que les performances ont été grandement amélioré dans bzr.
Ca me semble quand même un peu exagéré, et pas forcement respectueux des devs des autres systèmes (darcs, monotone, git, mercurial, ...)
non, pas forcément. Chacuns ont leurs avantages et leurs inconvénients. Vu que bzr essaie de prendre les bonnes idées des voisins, il a beaucoup de fonctionnalités. Darcs est surtout facile à utiliser, mais il n'est pas utilisable sur des projets de taille moyenne à grande. git ne fonctionne pas sous windows (cygwin, ca compte pas, hein ;-)). Mercurial a des fonctionnalités très proche de bzr, mais ses inconvénients face à bzr sont l'absence de renomage de fichier (copy+delete sous hg), le fait de ne pouvoir forker une nouvelle branche en local sans recopier tout l'historique uniquement s'il y a support des liens dur, ainsi qu'un support de windows pas aussi bon que bzr. (monotone, je connais pas)
Il n'en reste que hg est très rapide (bien que certaines parties soient programmé en C contrairement à bzr), et qu'a mon avis, le futur va se jouer entre bzr et hg.-
[^]choix
Posté par or zax () le 03/10/2006 à 07:43. (lien). Évalué à 7.Le choix va être vite fait pour tous ceux qui ont comme soucis la pérénité de leurs projets.
bzr est chapoté par Canonical, et quand on voit les promesses en l'air fait par rapport à bazaar première génération, que les utilisateurs se sont fait planter, avec un système plus maintenu, une politique de migration qui n'a pas plus de consistence que le vide inter-sidéral : utiliser une technologie géré par Canonical est un trop gros risque pour une utilisation professionnelle.
Moi c'est Mercurial, j'ai la tranquilité d'esprit maintenant.-
[^]Re: choix
Posté par ribwund () le 03/10/2006 à 07:54. (lien). Évalué à 7.bzr est chapoté par Canonical
D'ailleurs pour contribuer à bzr il faut assigner son copyright à Canonical, et je sais pas pourquoi mais je pense que Canonical c'est pas la FSF, ils font pas ça pour passer le logiciel en GPLv3 par la suite... (surtout sachant que Launchpad est propriétaire et qu'ils cherchent à integrer Launchpad+bzr au maximum)
-
[+] [^]Re: choix
Posté par champi (page perso, ) le 03/10/2006 à 08:58. (lien). Évalué à -1.Je trouve justement que le support de canonical perenise ce logiciel, notamment son intégration avec le portail launchpad.net qui fournit un moyen très simple de démarrer un projet open source sans avoir à configurer de serveur.
De plus la migration de repositories arch/baz -> bzr est toujours supportée AFAIK.-
[^]Re: choix
Posté par or zax () le 03/10/2006 à 09:58. (lien). Évalué à 5.Et bien regarde à quel point bazaar est pérenne, la sortie de baz 1.5 est toujours prévu pour 2005 ?
Pour information, une migration ne consiste pas juste en un utilitaire de conversion, c'est aussi un support. Il y a qu'a voir à quel point les développeurs normalement assigné à bazaar sont présent sur la mailing-list.
Tout une partie de ceux qui utilisait baz ont du choisir grosso-modo entre bzr et revenir à tla, car du jour au lendemain, canonical décide que
gérer correctement baz ce n'était plus assez fun.
Désolais mais canonical derrière des outils aussi important c'est dangereux, le fait qu'une société a de l'argent ne garantie pas de la pérennité, mais assujeti le projet au bon vouloir de la société en question.
Actuellement tous les copyrights sont au nom de canonical en plus d'après ce que je viens de lire, ce qui veut dire que Canonical peut rendre propriétaire du jour au lendemain bzr.
bzr c'est une bombe à retardement, amis kamikaze, amusez vous bien avec bzr, vous rigolerez moins après.-
[^]Re: choix
Posté par champi (page perso, ) le 03/10/2006 à 10:36. (lien). Évalué à 2.bzr est le successeur officiel de baz donc c'est normal qu'il faille upgrader son repository (ou rester avec la dernière version de baz si elle convient).
http://bazaar-vcs.org/HistoryOfBazaar :
Canonical Ltd had a need for a decentralized version control system. At the time, the closest fit to their need was Gnu Arch, however there was some difficulty in adapting it to fit their exact needs.
So Canonical created a Bazaar project. Initially it was thought that the fork of Gnu Arch now known as Baz-1.x would become the official Bazaar project. After some limitations in the Gnu Arch model had been uncovered, a prototype initially called Bazaar-NG was created. Eventually, this prototype became quite robust and easier to use.
Historically the project has had several names, but it is now just simply known as Bazaar.
Par ailleurs, un logiciel GPL ne peut pas "être rendu propriétaire", la version distribuée sous license GPL continuera d'être libre même si canonical décidait de publier une nouvelle version sous licence proprio. Et de toute manière ca serait suicidaire de leur part de le faire : leurs utilisateurs feraient un fork ou switcheraient en masse vers une autre solution si tel était le cas.-
[^]Re: choix
Posté par or zax () le 03/10/2006 à 11:29. (lien). Évalué à 4.Bon je me répète, une migration ne consiste pas juste à convertir un dépôt, le problème n'est donc pas la mise à jours, mais le suivie et le support, l'adaptation des procédures de développements etc ... chose que canonical avait promis de faire mais n'a pas fait.
Pour ce qui est de la licence GPL, focément, mais c'est gentil de toujours dire, la communauté peut reprendre, mais au bout d'un moment elle en marre de rattraper les dégâts, en plus cela divise les utilisateurs, suffit que la version proprio rende incompatible les versions suivantes avec la précédente et c'est le bazaar sans faire de mauvais jeu de mots.
bzr dans l'état actuel des choses (cela peut évoluer en bien et je l'espère) est une prise de risque inutile au vu de l'existant, et de la main mise de canonical.
-
-
[^]Re: choix
Posté par Matthieu Moy (page perso, ) le 03/10/2006 à 11:48. (lien). Évalué à 6.> Et bien regarde à quel point bazaar est pérenne, la sortie de baz 1.5 est toujours prévu pour 2005 ?
Non, non, après un an à crier haut et fort que la version 1.5 était juste retardée, mais pas abandonnée, Robert a bien annoncé qu'il abandonnait. Ils ont pas peur du ridicule ...
(pour rappel, je suis l'auteur d'une bonne partie des modifs commitées dans la branche 1.5 qui n'a jamais été releasée)
> ce qui veut dire que Canonical peut rendre propriétaire du jour au lendemain bzr.
Là, par contre, c'est faux. Le copyright assignment est là :
http://bazaar-vcs.org/CopyrightAssignment
voir le point 6. Canonical peut distribuer bzr sous une licence propriétaire, mais s'engage à le distribuer aussi sous une licence libre au sens de la FSF.
Perso, je n'ai aucune confiance en Canonical pour la maintenance à long terme, mais je crois qu'il y a suffisament de gens qui s'intéressent à bzr pour qu'un fork apparaisse si les gens de Canonical font les cons. Avec baz, ça n'était pas le cas, vu que quand ils ont abandonné leur bébé, la plupart des gens étaient déjà sous bzr, ou encore sous tla. Mais je peux me tromper.
-
-
-
-
[^]Re: Performances...
-
Monotone
C'est dommage qu'on ne parle pas plus de monotone je trouve. C'est vraiment bien conçu et tout à fait utilisable depuis un bout de temps. La version 0.30 est sortie il y a 2 semaines : http://venge.net/monotone/ .
Quelqu'un a posté récemment une comparaison de VCS dans comp.lang.ada :
http://www.ada-france.org/debian/distributed-version-control(...)
http://groups.google.com/group/comp.lang.ada/msg/bf2f9970828(...)
Il a choisi monotone :
I believe that Monotone is the Ada of version control systems, so it is only appropriate that I use it for my Ada work. Monotone is safe, correct and powerful _by design_. It uses cryptographic keys to authenticate changes. It is written by elite programmers who, despite using C++, have the "Ada attitude": no pointers, one assert() every 9 lines of code, massive use of generics (templates), and not a single critical bug in 3 years.
J'aime bien sa comparaison :
I like to think that...
CVS is the "C" of version control systems,
Subversion is the "C++" designed to replace the "C",
GIT is the "assembly language" who needs cogito to be useable,
Bazaar-NG is the "perl", grossly inefficient and completely baroque,
Mercurial is the "Eiffel" i.e the second best,
Monotone is the "Ada", i.e. the best, even if not perfect
(bon, bien sûr tout le monde sait que le meilleur langage de l'Univers c'est OCaml, pas Ada).
-
[^]Re: Monotone
Posté par golum () le 03/10/2006 à 09:48. (lien). Évalué à 4.Oui c'est vrai que l'approche de Monotone est vraiment élegante.
Une branche n'est pas une véritable branche au sens d'une séquence linéaire de version.
Il s'agit plutôt d'une notion logique qui s'apparente à un effort de développement. Elle ressemble plutôt à un fuseau de versions avec une étiquette.
Losrqu'on travaille dans une branche monotone, on n'a pas besoin de forker une branche pour travailler dasn son coin.
On se synchronise et committe sans se poser de question. Lorsqu'on récupère les modifs des autres dans son repository, Monotone detecte les version des fichiers qui ont divergé et on peut les réconcilier.
D'autre part Monotone implémente son propre système de synchronisation (netsync) même si il peut passer à travers tout autre type de protocole. L'approche est consistante et efficace.
Enfin le developpeur principal du projet est quelqu'un d'assez ouvert. Il s'etait rapporché des devs de Codeville pour échanger sur les algorithmes de merge. Il est à l'origine de la création du wiki
http://revctrl.org/FrontPage
sur lequel des devs des VCS les plus en vues sont inscrits
-
[^]Re: Monotone
Posté par golum () le 03/10/2006 à 11:07. (lien). Évalué à 5.
(I particularly dislike Subversion and its distributed derivative,
SVK. I do not recommend them because their working model is
inherently broken, IMHO. A branch is NOT a directory, and a tag is
NEITHER a branch NOR a directory.
Au contraire, je pense que c'est cette conception qui fait la force de svn.
Pour quelqu'un qui a pris l'habitude de faire des copies de sauvegardes de ses petits devs
en recopiant son arbo, c'est on ne peut plus naturel.
Mais surtout l'algorithme de tag/branche est en O(n) et la plupart du temps bien au dessous du cas limite.
Tous les développeurs qui ont déjà attendu 1h avant de tagger un gros projet sous Clearcase ou Perforce
peuvent témoigner.
Pour ceux qui veulent approfondir le sujet
http://subversion.tigris.org/files/documents/15/158/svn.zip
M'as l'air d'être un beau trolleur de compét le sieur.-
[^]Re: Monotone
Posté par Boa Treize (page perso, ) le 03/10/2006 à 11:44. (lien). Évalué à 3.Pfff, rien du tout, le vrai trolleur c'est Linus Torvalds ! :-)
I really don't think you can do it sanely.
The thing is, the reason subversion can do it is simply that SVN is terminally broken.
Really. SVN is crap. It may be prettier crap than CVS, but it's literaly no different from putting confectioners sugar on top of a cowpatty. It's not really "fixing" anything. And the revision numbering is actually very much part of the problem.
En adaptation libre :
Je ne pense vraiment pas que ça puisse être fait proprement.
Le truc, la raison pour laquelle subversion peut faire ça c'est simplement que SVN est une foirade irrémédiable.
Vraiment. SVN c'est de la merde. C'est peut-être une merde plus avenante que CVS, mais c'est littéralement la même chose que de mettre du sucre en poudre sur de la bouse de vache. Subversion ne "corrige" en fait rien du tout. Et la numérotation des révisions est un symptome typique des problèmes de subversion.
P.S. : Git n'a pas vraiment besoin de Cogito pour être utilisable, et n'est plus vraiment « l'assembleur dont il faut combiner les instructions » d'il y a un an...-
[^]Re: Monotone
Posté par golum () le 03/10/2006 à 12:24. (lien). Évalué à 1.Oui tu nous l'a déjà faite ici.
http://linuxfr.org/comments/756569.html#756569
Et alors comme Linus il l'a dit et ben c'est vrai.
Tout le monde sur DLFP va gober la divine parole du grand gourou.
Pour être un peu plus constructif, tu aurais pu nous fournir le reste de la conversation pour savoir ce qu'il reproche exactement la numérotation des révisions:
Le fait d'historiser les versions au lieu des diff comme Gnu Arch ?
Mieux tu pourrais nous fournir une petite analyse et poster un journal sur le sujet en t'en tenant à ses arguments-
[^]Re: Monotone
Posté par Boa Treize (page perso, ) le 03/10/2006 à 13:10. (lien). Évalué à 6.Le but est (était ?) de comparer les gros trolls velus que certaines grandes gueules bien connues peuvent pondre parfois.
Je n'ai en aucun cas prétendu que Linus avait raison, et d'ailleurs, comme je l'avais dit quand j'avais traduit son troll lors de la sortie de la dernière version de Linux, sur ce point précis il avait tort. (Mais son opinion sur Subversion demeure.)
Sur ce point précis :
Un utilisateur est venu demander si on pouvait modifier Git pour disposer d'un numéro de révision qui s'incrémente monotoniquement, pour pouvoir faire comme sur les projets qui utilisent Subversion, et dire simplement aux utilisateurs "utilise la révision 393" ou "c'est corrigé dans la révision 532".
Linus est parti de travers la dessus (ce qui lui arrive rarement), et a donc pondu ces phrases mémorables sur la qualité de CVS et Subversion (bon ça, ça lui arrive plus souvent), et notamment une grande tirade sur la numérotation des branches dans CVS (1.1.1.5, ce genre de trucs effectivement bien horrible mais qui n'avait rien à voir avec ce que l'utilisateur demandait).
Après un petit recadrage d'autres contributeurs de Git, les arguments suivants ont été retenus :
- C'est faisable dans Git, mais ça fait une métadonnée à mémoriser en plus, et un changement qui impacte pas mal de commandes de Git
- Communiquer une version abrégée de l'identifiant du commit concerné fonctionne aussi bien ("utilise le commit 5ef24" ou "c'est corrigé dans le commit 63b43")
- Ce genre de communication est plus liée à un projet organisé autour d'un référentiel centralisé et qui utilise peu de branches ; dans les projets plus distribués et/ou qui utilisent plus de branches, on a plutôt tendance à dire "utilise la branche new_features" ou "c'est corrigé dans la branche bugfixes".
Au final, vu tout ça, la conclusion a été "si quelqu'un le veut vraiment, qu'il propose un patch".
Sur Subversion et CVS :
C'est tout l'argument centralisé contre distribué, politique des projets, etc. qu'il faudrait reprendre. Ce que je ne vais pas faire là maintenant.-
[^]Re: Monotone
Posté par golum () le 03/10/2006 à 13:36. (lien). Évalué à 3.Merci pour ces précisions. Je reconnais que mon post etait un peu acide et je te prie de m'en excuser.
Tu fais partie de mes contradicteurs "préférés" sur les VCS et ton post paraissait ambigu. Sans plus de précision, j'ai extrapolé...a tort, n'ayant pas relu tout le thread sur la dernière sortie de Linux.
Comme on dit par chez nous, "je suis parti comme un pet sur une toile cirée"
A propos de Subversion et CVS je ne te demandais pas un argumentaire complet, on a déjà pas mal echangé sur le jet. Je souhaitais juste que tu précises les griefs argumentés du sieur Linus. Tu l'a précisé il était hors-sujet.
Le débat est clos et je serais mal placé pour lui en tenir rigueur.
-
[^]Re: Monotone
Posté par Vivi (page perso, ) le 03/10/2006 à 14:17. (lien). Évalué à 1.sur ce point précis il avait tort
Euh j'ai du mal à voir comment on peut avoir des numéros de révision incrémenentaux dans un système complètement distribué: il faut quelque part une autorité centrale qui vérifie qu'il n'y a pas de collision.
Bon évidemment dans le cas de Subversion y'a pas de problèmes vu que c'est centralisé.-
[^]Re: Monotone
Posté par champi (page perso, ) le 03/10/2006 à 14:22. (lien). Évalué à 1.Dans ce cas, on utilise des numéros de révisions propres à chaque branche (ce qui est le cas de BZR en tout cas).
-
[^]Re: Monotone
Posté par Boa Treize (page perso, ) le 03/10/2006 à 14:25. (lien). Évalué à 2.Une telle numérotation aurait bien sûr été limité au niveau du repository. Mais la plupart des projets ayant un seul repository officiel, la fonctionnalité aurait quand même pu être utile. Ceci dit, c'était effectivement un autre argument en défaveur de cette demande.
-
[^]Re: Monotone
Posté par golum () le 03/10/2006 à 14:32. (lien). Évalué à 1.Tu as aussi la solution de Monotone:
Calculer tous les hash sur les fichiers de la configuration (aborescence) et les mettre dans un fichier manifeste.
Et le hash de ce manifeste identifie la configuration-
[^]Re: Monotone
Posté par Boa Treize (page perso, ) le 03/10/2006 à 14:55. (lien). Évalué à 2.C'est ce que je mentionnais quand je parlais "d'identifiant du commit" plus haut. Sur ce point Git fonctionne comme Monotone je crois. (Mais je connais très peu Monotone.)
Ce que la personne voulait, c'était un numéro séquentiel.-
[^]Re: Monotone
Posté par golum () le 03/10/2006 à 15:25. (lien). Évalué à 2.Désolé j'avais compris que c'était un id de patch.
Un même patch peut être appliqué à plusieurs arborescences et ne suffirait donc pas.
Je ne connais pas git et je pensais qu'il avait la même architecture que Arch (historique basé sur les patchs/changeset et non sur les versions)-
[^]Re: Monotone
Posté par Boa Treize (page perso, ) le 03/10/2006 à 15:57. (lien). Évalué à 3.Si on ne connaît pas l'architecture de Git, c'est sûr que ce n'est pas facile à comprendre. J'aurais dû utiliser une formulation plus claire.
Rapidement :
Le coeur de Git, c'est de stocker des objets, et de les identifier par leurs somme de contrôle (SHA1 actuellement). Git ne gère que quatre types d'objets :
- le blob, qui est un gros tas d'octets dans lequel Git ne met pas son nez ; concrètement, les différentes versions des fichiers mis en conf sont stockées sous forme de blob
- l'arbre, qui contient des pointeurs vers des blobs et possiblement vers d'autres arbres ; c'est ce qui permet de mémoriser l'arborescence des fichiers
- le commit, qui contient un pointeur vers un arbre (la racine des fichiers dont on souhaite mémoriser l'état) et vers un ou plusieurs autres commits (les ancêtres de ce commit, ce qui permet de constituer l'historique du développement, et de gérer les branches)
- le tag, objet plus anodin qui pointe vers n'importe quel objet précédent, et porte un nom (genre v2.6.16.7) et optionnellement une signature.
Donc, comme Mercurial (et Monotone ?), Git stocke l'état des fichiers aux divers moments du développement, et génère le diff entre deux états à la volée. Contrairement à Arch ou Darcs, par exemple, qui stockent les diff et génèrent l'état à la demande.
Le reste de Git, c'est de la fioriture. ;-)
- Programmes de bas niveau pour gérer ces objets
- Programmes pour compacter tous ces objets en un pack qui consomme beaucoup moins d'espace disque et gérer ce genre de pack
- Programmes pour envoyer et recevoir ces objets par divers protocoles
- Programmes pour générer et digérer des patches de toutes sortes
- Programmes pour interroger les données dans tous les sens (diff, grep très puissant, logs plus ou moins verbeux, etc.)
- Programmes pour chercher à quel endroit on a introduit un bug
- Programmes pour importer les données d'autres gestionnaires de conf
- Programmes pour encore plein de trucs divers et variés plus ou moins annexes
- Et bien sûr programmes de plus haut niveau pour pas se prendre la tête dans la vie de tous les jours ;-)
Le tout étant à peu près correctement documenté. Git a fait beaucoup de progrès depuis ses débuts. :-)
Doc pour débuter :
Everyday Git
http://www.kernel.org/pub/software/scm/git/docs/everyday.htm(...)
Vue d'ensemble
http://www.kernel.org/pub/software/scm/git/docs/
-
-
-
-
-
-
-
[^]Re: Monotone
Posté par Christophe Fergeau () le 03/10/2006 à 16:25. (lien). Évalué à 2.A mes yeux, c'est pas trop dur de comprendre pourquoi linus aime pas svn. La facon dont il bosse pour le noyau, c'est de merger en permanence des patches en provenance d'une multitude de branches. Et bon, que ça soit svn ou cvs, le merge répété d'une branche dans un repo, c'est déjà pas ça du tout...
En plus, vu comment c'est développé le noyau, je pense pas que linus soit intéressé par un scm centralisé, donc il a pas dû passer beaucoup de temps à regarder svn ou cvs.-
[^]Re: Monotone
Posté par Boa Treize (page perso, ) le 03/10/2006 à 16:32. (lien). Évalué à 2.Ca va plus loin que ça : il connaît et a toujours détesté CVS, il a regardé et n'aime pas beaucoup plus Subversion.
D'ailleurs, après avoir utilisé un truc proprio qui lui convenait bien, il a créé son propre truc qui lui convient bien. ;-)
-
-
-
-
Repository sur Launchpad
Je viens de découvrir quelque chose de très intéressant, il suffit d'avoir un compte sur Launchpad pour pouvoir créer des branches sue le serveur launchpad, et les partager avec le reste du monde.
Ca peut être fait avec n'importe quel hébergement HTTP, c'est vrai, mais là ou c'est plus intéressant, c'est que tu peux dans launchpad créer des groupes et travailler à plusieurs sur la même branche.
Et là, je n'ai pas encore trouvé d'hébergement gratuit permettant d'avoir plusieurs login/mot de passe pour le même espace de stokage.
https://launchpad.net/bazaar
Cette page a été générée par Templeet en 0.1386s (dont 0.0215 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.