Linus Torvalds a passé ces derniers jours à tester différentes solutions SCM [source code management] et a commencé à écrire un content tracker nommé git pour remplacer BitKeeper. D'autres développeurs ont contribué des idées et du code à ce petit outil, au point qu'au bout de moins d'une semaine, il est prêt pour un test grandeur nature. Andrew Morton vient d'envoyer un email titré "Incoming" sur la linux-kernel mailing-list, suivi de deux centaines de patches, qui vont être intégrés à l'arbre officiel par l'intermédiaire de git.
Espérons que les développeurs du noyau pourront être aussi efficaces avec git qu'ils l'étaient avec BitKeeper. La rapidité de ce changement d'outils laisse à penser que l'on peut être optimiste à ce sujet.
Aller plus loin
- Le README de Git (56 clics)
- "Incoming", le mail de Andrew Morton (44 clics)
- DLFP: Bitkeeper: plus de version gratuite (24 clics)
# précisions ?
Posté par TImaniac (site web personnel) . Évalué à 8.
J'ai pas très bien capté l'intérêt de l'outil développé Linus par rapport aux solutions existantes... c'est complémentaire ou pas ?
[^] # Re: précisions ?
Posté par galactikboulay . Évalué à 6.
pas du tout comment c'est censé être utilisé de manière distribuée
par les développeurs du noyau (ça cause en réseau ?). Le README
explique comment fonctionne l'outil, pas comment il est utilisé.
On lit que Linus a testé plusieurs SCM, oui mais il en a retenu un ou
pas ? si oui lequel, et si non pourquoi, quels sont les manques des
outils actuels ?
[^] # Source
Posté par galactikboulay . Évalué à 8.
http://www.kernel.org/pub/linux/kernel/people/torvalds/(...)
La dernière version est la 0.04.
[^] # Re: Source
Posté par wismerhill . Évalué à 6.
[^] # Re: Source
Posté par let antibarbie = xp <- xp - 1 . Évalué à 6.
Le coup de la version bêta déjà prête à tester, c'est un tr.... bien poilu à mon avis.
Maintenant si tout ce raffut pouvait inciter un grand nombre de développeurs à se joindre au développement d'outils SCM performants et libres, c'est très bien ! Des outils SCM libres, y'en a plein, mais ils sont pas tous très matures ! et ils n'ont pas tous la jolie interface graphique qui va avec pour convaincre le patron que c'est un bon choix.
[^] # Re: Source
Posté par gabuzo . Évalué à 2.
[^] # Re: précisions ?
Posté par Gniarf . Évalué à -7.
[^] # Re: précisions ?
Posté par bmc . Évalué à 10.
Voilà ce que j'en ai compris. Les corrections sont les bienvenues :)
[^] # Re: précisions ?
Posté par Colin Leroy (site web personnel) . Évalué à 6.
Mais il faut dire que c'est assez pointu comme concepts, alors ne prenez pas ce que je dis comme argent comptant.
[^] # Re: précisions ?
Posté par GhZaaark3 . Évalué à -4.
ça sert pas à grand chose vu que Torvalds en refuse pas mal :p
parcontre je ne savais pas que la team du noyau linux utilisait un soft non-libre pour sa maintenance.
+
# L'info sur kerneltrap
Posté par bmc . Évalué à 7.
RIen de bien transcendant : l'échange sur la liste du noyau, et deux trois commentaires qui valent la peine qu'on les lise.
[^] # Re: L'info sur kerneltrap
Posté par Edouard Gomez (site web personnel) . Évalué à 10.
Il a à peine évoquer les raisons qui l'ont poussé à rejeter Monotone. N'a pas cité Arch, ni Darcs. Je parlerai principalement d'arch/tla ou bazaar car c'est le SCM que j'utilise depuis plus de 2 ans, mais j'ai aussi regardé du coté de Monotone recemment, voir du tres tres jeune bazaar-ng (plus proche de monotone dans sa gestion du tracking des sources).
Ayant utilisé arch/tla, je sais que ce n'est pas une solution viable aujourd'hui, car tla (ou bazaar) se trainent des problemes de conception qui remontent au prototype arch/larch codé à coup de sh/gawk/gnutar/gnudiff par Tom Lord qui cherchait à valider les idées fondatrices de son futur outils de versionning. Je ne donnerai ici que quelques examples:
- le gachi monumental d'inode pour l'historique (qui devient un cauchemar sur des FS comme ext2/3, et est un peu pres vivable sur des FS comme ReiserFS qui merge les petits fichiers directement dans l'inode).
- des conventions de nommage qui sont bien loin de toutes les habitudes
- une CLI trop centrée autour du design interne du code et pas assez orienté user (c'est ce que tente de reparer bazaar)
- une redondance monstre dans le suivi des patchs mergés (c'est pas optimal, mais ca marche)
- des doublons dans les possibilités laissées a l'utilisateur pour avoir un tla efficace (pristines trees hardlinkés, revision libraries...)
- une documentation qui se ne couvre meme pas tout car le dev de tla a connu une periode tres riche et la doc n'a jamasi suivi).
Vu comme ça, arch/tla ou bazaar peuvent sembler bien nuls, mais en fait pour des projets de taille raisonnable (pas un noyau linux en somme), c'est largement suffisant à condition de s'imposer quelques restrictions sur sa gestion des archives. C'est pour ça, que je continue à utiliser bazaar.
Aussi, Andrea Arcangeli (auteur de la VM des noyaux >= 2.4.10 iirc) avait jeté un coup d'oeil sur tla, et avait proposé des améliorations qui auraient permis à des dev de bosser sur des arbres de source comme linux. Il avait réussi à obtenir plus ou moins le type de résultats que Linus obtient aujourd'hui avec son outil GIT pour la génération d'un patchset entre deux arbres... mais bon d'autresdéfauts de tla me font croire que tla n'est pas capable de gérer les quelques 60000 patchsets du noyau 2.5/2.6 par exemple. Sur XviD avec seulement 600 patchs, y'a des fois ou je me dis que arch/tla a quelques defauts :-).
Enfin bon, ce que code Linus, est plus proche du mode de fonctionnement de Monotone, qui maintient un inventaire des fichiers de source en leur attribuant leur somme SHA1, que de arch/tla.
Puis certes, comme le dit Linus, Monotone est lent. Mais je trouve plus que dommage, qu'au lieu d'investir un peu (tant en termes d'efforts de dev ou d'argent) sur l'evolution d'un SCM decentralisé existant qui serait utilisé par les devs de Linux, bah Linus choisit la voie du "je me fais ma sauce dans mon coin".
Bizzarement sur la LKML, personne ne semble s'en rendre compte et tout le monde se penche sur ce GIT que "comme c'est Linus qui code, c'est trop de la bombe, faut trop que je mette mon nom dans le AUTHORS".
PS: je sais, que mes propos peuvent sembler prétentieux, mais si on reflechi deux nanosecondes, c'est pas bien dur de voir que Linus s'embarque dans un choix qui risque d'engendrer un outil purement dédié à SES besoins et à rien d'autre. Bref un peu un gachi, car il va monopoliser des forces de développement dont auraient pu profiter plus de personnes en travaillant sur un SCM plus générique.
[^] # Re: L'info sur kerneltrap
Posté par Frederick Ros . Évalué à 7.
Je suis assez d'accord avec toi ... Le syndrome du "Not invented here" ?
[^] # Re: L'info sur kerneltrap
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 8.
Et alors ? Le plus important dans l'histoire, c'est qu'il ait un outil qui réponde à SES besoins. Le plus important, c'est de développer le noyau linux, pas de participer au développement d'un SCM existant qui ne répond pas à SES besoins.
Participer à un truc déjà existant, c'est trés dur : il faut déjà avoir le temps de se plonger dans le code existant; il faut avoir le temps de tisser des liens avec les développeurs actuels. Discuter des évolutions avec les développeurs actuels, ça prend beaucoup de temps. Sans être sûr au bout du compte que les évolutions qu'on veut soient accépté. Bref, on arrive pas dans un projet existant comme ça, en voulant le diriger pour qu'il corresponde à nos propres besoins (qui sont urgents, dans le cas de linus). C'est donc beaucoup de temps perdu.
C'est pour ça que linus a préféré développer son truc dans son coin : il sait au moins que ça correspondra à ses besoins, que ça ira au moins aussi vite (la preuve..) que l'intégration d'un projet existant (dont aucun ne semble répondre à ses besoins), et qu'il n'aura pas à se prendre la tête avec d'autres développeurs.
Je ne vois pas où est le mal.
C'est sûr que les premières versions de son truc, c'est pas universel. Ça n'est pas forcément générique. Le principal c'est que ça réponde à SES besoins immédiats. Mais peut être aussi qu'à l'avenir, quand il répondra à TOUT ses besoins, le soft évoluera de façon à satisfaire à des besoins moins urgent, plus universel.
D'ailleurs, je te rappelle que "répondre à ses propres besoins", c'est un peu la philosophie du logiciel libre ;-) Si t'es pas content, envoie un patch :-p Et si t'es vraiment pas content, développe un autre produit "concurrent".
[^] # Re: L'info sur kerneltrap
Posté par Frederick Ros . Évalué à 2.
C'est vrai .. pourquoi developper pour le noyau. Autant acheter Winblows XP, au moins y'a pas besoin de regarder des sources pour essayer de comprendre/fixer un bug et par la-meme en faire profiter d'autres ,,,
D'ailleurs, je te rappelle que "répondre à ses propres besoins", c'est un peu la philosophie du logiciel libre ;-) Si t'es pas content, envoie un patch :-p Et si t'es vraiment pas content, développe un autre produit "concurrent".
De ce que j'ai vu, Monotone etait considere comme "trop lent" .. Je crois pas qu'il se soit donne la peine de poster un patch pour qu'il soit plus rapide et par la-meme aider la communaute des utilisateurs de Monotone (dont je ne fais pas partie).
Avec cette philosophie la, on aurait eu 10.000 OS libre au lieu d'avoir 10.000 personnes aidant a developper un OS.
[^] # Re: L'info sur kerneltrap
Posté par Jean . Évalué à 10.
Et dans le Changelog de la dernière version de monotone (0.18) sortie le 10, on peut lire:
mes 0.02¤
[^] # Re: L'info sur kerneltrap
Posté par Frederick Ros . Évalué à 3.
[^] # Re: L'info sur kerneltrap
Posté par Yohann (site web personnel) . Évalué à 1.
je disparais ---> *pouf*
[^] # Re: L'info sur kerneltrap
Posté par Sylvain Sauvage . Évalué à 2.
Alors deux fois plus courte : est-ce qu'on coupe la fin ou s'en rapproche d'un grand coup ?
Parce que soit ça rend la fin moins longue, soit on trouve l'éternité longue plus tôt...
Moi, je prends la porte, c'est classique mais moins tape à l'½il. Hop, hop -->[]
[^] # Re: L'info sur kerneltrap
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
Je ne vois pas le rapport avec le schmilblick.
Je parlais du cas de l'opportunité ou non d'intégrer une équipe déjà en place.
concernant le noyau, Linus n'a pas eu ce cas de figure, puisque c'est lui, qui a démarrer le projet de ce noyau.
Et pourquoi d'ailleurs ? parce que ce qui existait alors ne correspondait pas à ses besoins.
Si windows correspondait à ses besoins à l'époque, on aurait effectivement pas de linux. Mais où aurait été le mal, si le produit correspondait à ses besoins ?
[^] # Re: L'info sur kerneltrap
Posté par Frederick Ros . Évalué à -1.
Je parlais du cas de l'opportunité ou non d'intégrer une équipe déjà en place.
C'est bien ce que je disais .... C'est plus dur d'integrer l'equipe de dev Linux que de passer direct sous Winblows.
Si windows correspondait à ses besoins à l'époque, on aurait effectivement pas de linux. Mais où aurait été le mal, si le produit correspondait à ses besoins ?
Il n'y a aucun mal.. mais si chaque contributeur Linux avait fait pareil, on en serait a XXX OS libres ..
[^] # Re: L'info sur kerneltrap
Posté par ouah (site web personnel) . Évalué à -4.
Et alors? Alors y en a marre des caprices de Linus. Il n'est pas seul à développer le noyau et son attitude est exaspérante pour les autres développeurs qui s'impliquent pour la communauté du libre.
L'avis des autres développeurs devrait être entendu et une solution consensuelle choisie. Au lieu de cela, comme d'habitude il n'en fait qu'à sa tête. (Généralement, il demande aux gens de faire des propositions, répond par des "ça sux" et finalement décrète qu'il retient la solution X). Pas très démocratique tout cela...
[^] # Re: L'info sur kerneltrap
Posté par wilk . Évalué à 9.
Hors pour comprendre les SCM afin d'en choisir un, le meilleur moyen c'est d'en écrire un sommaire, ça permet de voir quels sont les problèmes, comment les autres les ont réglés, quelle vitesse maximale on peut atteindre etc... Le GIT sert à ça, se pencher sur le problème et en même temps avoir un premier outil que l'on maitrise parfaitement.
Le fait qu'on soit dans le monde du libre, il sera facile de repartir de ce GIT pour utiliser un autre SCM, il sera aussi plus facile pour les autres developpeurs d'utiliser un SCM différent de celui de Linus.
Martin Pool, le développeur de bazaar-ng a déjà signalé qu'il n'exclurait pas l'idée d'utiliser du code de GIT au sein de son moteur.
C'est vraiment du développement distribué pour des scm distribués !
[^] # Re: L'info sur kerneltrap
Posté par or zax . Évalué à 3.
De plus sur la lkml, et par des mails privés, Linus THORVALD a reçu des benchmarks sur l'intégration de tous les changesets, du noyau, ainsi que des benchmarks sur des cas d'utilisation, à la fois côté mainteneur et côté développeur.
L'utilisation de Arch sur le plan performance ne pose aucun problème, j'ai moi même fait des tests poussés, en respectant la règle du "je test dans le pire des cas".
La question est est-ce que la logique de Arch lui plait ou non ? Monotone semble plus lui convenir, et enfin, après les longues discussions enflammés ou il a dut défendre bec et ongle bitkeeper par rapport à l'utilisation des autres solutions, va-t-il avoir le courage de se tourner vers des solutions qu'il avait cassé ? (souvent à juste titre, on compare avec le niveau actuel des outils, mais auparavant c'était catastrophique).
GIT est la solution facile.
Mais peut importe il faut voir si cette solution à une perennité, si ce n'est pas le cas, développer son propre outils ne sert à rien et ne fait que reculer l'échéance et gaspiller les efforts
[^] # Re: L'info sur kerneltrap
Posté par oliv . Évalué à 4.
Linus a passé 5 jours a évaluer les solutions existantes, et aucune ne lui a semblé idoine. Donc il a dû écrire lui même un programme qui réponde à ses besoins.
Oui "git" est la solution facile. Il fallait dans l'urgence remplacer Bitkeeper, et la solution facile était devant cette contrainte la solution idéale.
[^] # Re: L'info sur kerneltrap
Posté par or zax . Évalué à 1.
Mon intervention visait à replacer certains point notamment par rapport aux performances.
Linus Torvalds à une grande masse de travail d'incorporation à faire et il ne souhaite pas changer ses habitudes, ce qui est légitime.
Ce qui m'inquiète plutôt est la perennité du GIT, tant qu'à développer quelque chose, il faut que çà dure, sinon on ne fait que retarder la résolution du problème.
Le temps portera donc conseil, en espérant que le choix de Linus se révélera être le bon, car pour l'instant il essait de faire quelque chose qui réponde à se besoins.
[^] # Re: L'info sur kerneltrap
Posté par ragoutoutou . Évalué à 6.
Oui, mais dans le fond, ça reste d'abors son joujou... Il en fait ce que bon lui semble, et c'est tout... c'est son droit...
Quand on est développeur et qu'on veut contribuer, on sait à quoi on s'engage et qui est le chef du projet.
Je serais à sa place, je n'aimerais de toutes façons pas me faire imposer "démocratiquement" une méthode de travail pour un projet que j'ai mis sur pied moi même durant mon temps libre.
Maintenant, si il pousse le bouchon trop loin, peut-être verrons-nous un fork du kernel, mais ça, c'est à lui de gérer.
Sinon, ceux qui ne sont pas d'accord peuvent toujours bosser sur Hurd...
[^] # Re: L'info sur kerneltrap
Posté par gallenza . Évalué à 3.
Tu préfères un noyau Linux (démocratique et pourrave) ou (totalitaire et performant) ? La démocratie c'est bien pour certaines choses, mais faut arrêter de la ressortir n'importe où quand ça n'a rien à y fouttre.
[^] # Re: L'info sur kerneltrap
Posté par fmaz fmaz . Évalué à 4.
Qu'est-ce qui force à ce qu'ils trouvent un remplaçant à BT si vite.
D'accord, BT change de licence et ne sera plus libre mais la
version actuelle est encore utilisable. Non?
Et si changer de système n'est pas si urgent, qu'est-ce qui empèche
Linus et ses acolytes de s'intéresser à un système existant pour
l'améliorer?
De (très) loin, ça me semble plus une réaction épidermique de
quelqu'un pris en flagrant déli de s'être planté (merde, ce connard
de RMS a eu raison) et qui veut changer le plus vite possible pour
montrer que ce qu'a dit RMS n'était pas si grave (BT, c'est bien
mais regardez, en 10 minutes, je m'en passe).
Se dire qu'on écrit un petit hack super spécifique et que les autres
vont améliorer, c'est:
1. mépriser les autres qui devront faire un gros boulot pour au final
devoir presque tout réécrire;
2. mépriser ceux qui travaillent depuis longtemps (à 2) sur des
systèmes génériques qui voient 100 mecs se ruer sur 100 lignes
de code du dieu Linus (ça me ferait mal ça);
[^] # Re: L'info sur kerneltrap
Posté par Anomaly . Évalué à 2.
> D'accord, BT change de licence et ne sera plus libre mais la
> version actuelle est encore utilisable. Non?
Non, il semble que Bitkeeper ne sera plus utilisable dans 3 mois.
Extrait de l'article KernelTrap :
> Over the next three months, BitMover intends to phase out
> the free BitKeeper product.
[^] # Re: L'info sur kerneltrap
Posté par let antibarbie = xp <- xp - 1 . Évalué à 0.
mais c'est le changement de politique concernant la version libre qui les a poussés à changer... de toutes façons une version libre *figée* de bitkeeper restera disponible, donc il n'y a aucune urgence AMHA.
[^] # Re: L'info sur kerneltrap
Posté par Éric (site web personnel) . Évalué à 1.
[^] # Re: L'info sur kerneltrap
Posté par Vincent Danjean . Évalué à 2.
Donc tous les projets utilisant BK et voulant permettre des commit sans acheter de licence doivent migrer avant le 1er juillet
[^] # Re: L'info sur kerneltrap
Posté par fmaz fmaz . Évalué à 2.
Je ne comprens plus rien.
J'avais compris que BitMachin était un SCM distribué, que Linus
l'avais choisi pour ça et que d'autres systèmes étaient caca
parce qu'ils étaient centralisés.
Et là, tu me dis qu'il suffit qu'une seule machine contrôlée par
BitDidule ferme et pouf, on ne peut plus faire un seul commit?
Merde, ils ont changé la définition du mot distribué sans me
prévenir.
Plus sérieusement, y a-t-il quelqu'un pour m'expliquer comment
fonctionne ce truc?
[^] # Re: L'info sur kerneltrap
Posté par let antibarbie = xp <- xp - 1 . Évalué à 1.
[^] # Re: L'info sur kerneltrap
Posté par reno . Évalué à 3.
Tu en sais en Français, il n'y a pas l'ambiguité free/Free de l'Anglais, autant en profiter!
[^] # Re: L'info sur kerneltrap
Posté par Thierry . Évalué à 5.
Il était une fois un jeune finlandais un peu fou. Seul dans sa chambre, dans la pénombre, face à son écran, il affichait "ABABABABA" afin de pouvoir ensuite écrire un émulateur de terminal pour lire fr.comp.minix sur l'ordinateur de son université.
Le reste est l'Histoire.
[^] # Re: L'info sur kerneltrap
Posté par Frederick Ros . Évalué à 2.
[^] # Re: L'info sur kerneltrap
Posté par ragoutoutou . Évalué à 4.
- déterminer qui a le droit de vote
- déterminer si chaque personne ayant un droit de vote possède le même nombre de voies
- organiser le vote
- appliquer le résultat du vote au risque de voir des développeurs quitter le navire, y compris Linus...
Pour moi, la "dictature éclairée" de LT est plus performante.
C'est son projet et je ne vois pas pourquoi qui que ce soit qui ne fait pas partie des kernel dev aurait la prétention de lui dire comment diriger sa barque.
[^] # Re: L'info sur kerneltrap
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Ensuite, j'ai l'impression que tu n'as pas saisie la notion du temps.
Si Linus a décidé de créer un nouvel outils, c'est trés certainement parce qu'il pense qu'il mettra beaucoup moins de temps à le développer qu'à integrer un projet existant, à se mettre d'accord avec les devs etc...
bref, compare ce qui est comparable.
[^] # Re: L'info sur kerneltrap
Posté par bmc . Évalué à 2.
D'un autre côté, on peut comprendre le souhait de Linus : je me suis fait avoir une fois, cette fois je fais mon propre truc comme ça personne ne pourra venir m'arnaquer. Soit dit en passant, ça traduit une certaine méconnaissance des licences, mais tout le monde sait que Linus se brosse un peu des licences ;)
[^] # Re: L'info sur kerneltrap
Posté par ragoutoutou . Évalué à 1.
[^] # Re: L'info sur kerneltrap
Posté par Philippe F (site web personnel) . Évalué à 4.
Dans un mail, il disait qu'il avait facilement chaque jour 200 patchs a integrer pour une personne. Si integrer un patch prend 30 secondes, 200 patch, ca fait 1h20, ce qui ne semble pas le temps dont Linus a a sa disposition. Partant de la, on comprends qu'il developpe son truc, qu'a l'air pas mal et qui resoud aussi un autre probleme, le probleme de la confiance.
Linux est developpe avec une dictature bienveillante. Si tu veux une democratie, tu peux faire un fork du noyau qui sera developpe democratiquement avec un gestionnaire de source choisi democratiquement, auxquels les developpeurs du noyau contribueront pour qu'il arrive a gerer les 60 000 fichiers du noyau. Bonne chance !
[^] # Re: L'info sur kerneltrap
Posté par ragoutoutou . Évalué à 2.
Je crois que tu as compris mon message à l'envers, je suis absolument du même avis que toi.
[^] # Re: L'info sur kerneltrap
Posté par ZeroHeure . Évalué à 7.
ça alors!
Il avait fait pareil pour Linux puis tout le monde a ajouté un tas de truc partout... Linux "n'était pas portable et ne le serait jamais" (LT), mais ALan Cox s'est acharné sur le port pour m68k et Linux est devenu portable... ;-)
Autant le reste de ton propos est pertinent autant là c'est un peu tôt pour dire Linus s'embarque dans "un gachi". Tu dis toi-même que tu gères un beaucoup plus petit projet et qu'à son échelle les besoins ne sont pas les mêmes...
Enfin j'ai du mal à croire que Linus soit un imbécile pas pragmatique du tout.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: L'info sur kerneltrap
Posté par Edouard Gomez (site web personnel) . Évalué à 4.
Je tiens juste a dire que mes propos n'ont jamais présenté Linus comme un imbécile. Ce sont tes propres conclusions.
Aussi je voudrais répondre à l'argument "Linus a bien codé Linux ! C'etait spécifique".
Sauf que les deux cas sont peu comparables.
Dans le cas de Linux, il n'y avait pas de noyau Unix-like tournant sur le i386 que Linus utilisait. Minix avait une architecture qui ne correspondait pas tout a fait au modele unix traditionnel, de plus la license ne convenait pas. Et a l'epoque 386BSD n'existait pas si je me trompe pas.
Aujourd'hui Linus a au moins 3 projets sur lesquels se pencher, avec une license qui convient. Dans les 3 cas, ca peut faire ce qu'il cherche a faire, c'est a dire stocker/manager des changesets.
L'excuse du manque de temps pour faire accepter ses vues dans les divers projets, c'est une excuse bien tardive. Il a eu 3 ans pour chercher un remplacant. Or pendant 3 ans, il n'a fait que demonter (verbalement) les solutions de rechange proposées par divers kernel dev (dont Arcangeli) et retorquait toujours que BK lui convenait et tant qu'aucun projet libre ne donnerait exactement les meme features, il utiliserait BK. Or aujourd'hui bizarrement, GIT ca va lui convenir, or GIT c'est un embryon de SCM, bien loin de couvrir ce que fait BK, et Monotone/Darcs/Arch....
Alors maintenant qu'il reparte dans une implementation d'un simili-SCM-tronqué dont on peut douter de la durée de vie, ca me derange pas du tout. Il est libre de faire ce que bon lui semble. Par contre, qu'il chippe les forces de dév en attirant des gens sur un projet à la durée de vie contestable (solution de rechange d'après ses dires), et dont la communauté de l'OSS ne pourrait pas profiter car trop Linux-centré, je trouve ça un peu dommage.
[^] # Re: L'info sur kerneltrap
Posté par Philippe F (site web personnel) . Évalué à 5.
Bizarre en effet qu'un logiciel qu'il developpe lui-meme lui convienne. C'est encore plus bizarre, que pendant 3 ans il critique les divers SCM et que au bout de 3 ans, tout d'un coup, il ne se mettent pas a convenir par un coup de baguette magique. Dans tes bizzareries, j'y verrai juste une opinion technique persistante.
> GIT c'est un embryon de SCM, bien loin de couvrir ce que fait BK, et Monotone/Darcs/Arch....
Il faut voir que Linus n'utilise pas un SCM de facon traditionelle. D'habitude, les SCM servent a partager du code et a garder une tracabilite. Dans le cas de Linux, le gestionnaire doit permettre a Linus de lire et d'integrer rapidement les patchs qu'on lui soumet avec une contrainte majeur de vitesse.
Les divers SCM dont tu parles n'ont pas ete developpe dans ce contexte et il n'est pas surprenant qu'ils ne conviennent pas parfaitement.
> Par contre, qu'il chippe les forces de dév en attirant des gens
Il ne vole personne, les gens sont libres de travailler sur ce que bon leur semble. Est-ce qu'on se plaint que KDE vole des forces de dev Gnome ?
> sur un projet à la durée de vie contestable
Dans la mesure ou c'est un projet central du noyau, sa duree de vie sera incontestablement liee a la duree de vie du noyau. Autant dire que pour l'instant, c'est partie pour longtemp.
> dont la communauté de l'OSS ne pourrait pas profiter car trop Linux-centré, je trouve ça un peu dommage.
La communaute des developpeurs du noyau profite. En fait, tu lui reproches de bosser trop sur Linux ? Pourquoi ne pas lui demander de bosser pour KDE aussi ?
[^] # Re: L'info sur kerneltrap
Posté par Christophe Fergeau . Évalué à 5.
Oui, tous des voleurs les kdeistes, rendez-nous nos développeurs!!! ;)
> Pourquoi ne pas lui demander de bosser pour KDE aussi ?
Pour GNOME c'est mieux :p
[^] # Re: L'info sur kerneltrap
Posté par ZeroHeure . Évalué à 2.
Linus Torvalds ne semble pas regarder plus loin que ses besoins immediats.
(...)
Il a à peine évoquer les raisons qui l'ont poussé à rejeter Monotone. N'a pas cité Arch, ni Darcs.
Par imbécile pas pragmatique je voulais dire qu'il a certainement testé les autres outils et que son côté pragmatique a du entrer en action.
Et puis après tout Linus peut très bien trouver super fun de coder un SCM! et s'il code un outil qui lui convient, cet outil a de forte chance de convenir à d'autres gros projets. C'est d'ailleurs comme ça que l'histoire de Bit Keeper a commencé: un outil d'abord conçu pour les besoins de Linus.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: L'info sur kerneltrap
Posté par ZeroHeure . Évalué à 5.
On a tous codé un truc nouveau plutôt qu'adapter un existant!
Tu te rappelle le temps où les hommes étaient des hommes et se bagarraient avec les bits? (C'est LT qui parle)
On a tous voulu avoir les mains sales et pleines de cicatrices des codeurs fous, la fierté du hacker qui voit s'éteindre les réverbères au matin, et qui rejoint son lit après une nuit de chasse au bug acharné.
Vive les mains dans le camboui! Je me suis écrit un clone de Vignette (c'était en 1999), j'ai même refait tout le site salon.com avec, c'était génial de code pourri, de café froid, de bugs inavouables et de nuits blanches dans la gueule. J'ai pris des mois de retard, mais quand les premiers utilisateurs sont arrivés j'en aurai foutu ma bite sur la lune!
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: L'info sur kerneltrap
Posté par Olivier Jeannet . Évalué à 4.
NetBSD existait je crois (pas sous ce nom-là, mais d'après l'URL plus bas "Networking Release 2" : "our second greatly expanded freely-redistributable release began shipping in June 1991"), mais il y a eu la poursuite de USL (Unix System Laboratories) contre l'université de Berkeley et ça a dû écarter pas mal de monde du projet à l'époque.
J'ai déjà lu que si BSD n'avait pas souffert du procès (qui a été abandonné grâce à Ray Noorda quand il est arrivé à la tête d'USL, suite à son rachat par Novell), il serait peut-être à la place de Linux actuellement, et que Linux n'aurait pas connu un tel essor.
Pour plus d'infos, cf http://ezine.daemonnews.org/200312/editorial.html(...) par ex :
Shortly after BSDI began their sales campaign, they received a letter from Unix System Laboratories (USL) (a mostly-owned subsidiary of AT&T spun off to develop and sell Unix). The letter demanded that they stop promoting their product as Unix. [...] This turned into a lawsuit against BSDI and The University of California, Berkeley, and came to include FreeBSD and NetBSD.
Conclusion du procès, commencé début 1992 : a settlement was finally reached in January 1994. The result was that three files were removed from the 18,000 that made up Networking Release 2, and a number of minor changes were made to other files. In addition, the University agreed to add USL copyrights to about 70 files, although those files continued to be freely redistributed.
Pour l'historique de BSD, y compris le procès de USL/AT&T : http://www.oreilly.com/catalog/opensources/book/kirkmck.html(...) .
[^] # Re: L'info sur kerneltrap
Posté par Vivi (site web personnel) . Évalué à 10.
Des raisons de performances principalement. Et aussi monotone n'est pas "prêt", c'est ce qu'on lui a dit : il y a encore des bugs, l'UI n'est pas vraiment fignolée, on peut être ecore amené à faire des grands changements dans les concepts, etc.
En fait git reprend de trés trés près la structure de monotone. Les grosses différences sont :
- monotone utilise une base sql
- monotone stocke des diffs entre fichiers alors que git stocke les fichiers entiers
- monotone possède des métadonnées signées
- git effectue le transport réseau via rsync alors que monotone a son propre protocole.
Sinon les données sont organisées de la même façon, en 3 couches :
- les fichiers, identifiées par le SHA1 hash de leur contenu ;
- les arbres, ("tree" pour git, "manifest" pour monotone) représentant un état de l'arbre à un moment donné ;
- ce qu'on appelle les "revisions" dans monotone, ("commit" pour git) référençant un abre et l'historique qui y a conduit.
J'écrit une petite application pour visualiser les graphes monotone :
http://oandrieu.nerim.net/monotone-viz/(...)
En bidouillant un peu (réécriture d'un module), je peux aussi afficher les graphes pour git:
http://oandrieu.nerim.net/monotone-viz/Screenshot-git-viz.png(...)
[^] # Re: L'info sur kerneltrap
Posté par Jérôme Marant . Évalué à 3.
A mon sens, le problème majeur de tla s'appelle Tom Lord
donc il n'y a rien à attendre de mieux à l'avenir. Il suffit de lire
les listes de diffusion pour voir passer tout un tas de délires
fumeux (Pika, XL, Furth) et l'autisme par rapport aux désirata des
utilisateurs.
Personnellement, j'utilise bazaar car c'est une bonne amélioration
de l'interfaçe de tla, même s'il se traine tous les défauts. C'est
un outil transitoire en attendant mieux.
darcs est très agréable mais pas très performant.
montone est très lent et l'idée de mettre tout le repository
dans une base sqlite n'est pas franchement ingénieux.
A mon sens bazaar-ng est très prometteur. La documentation
est riche. Le but n'est pas de réinventer la roue mais de
prendre le meilleur de tous et d'en faire quelquechose
d'apréciable. Qu'en penses-tu ?
# Rapidité étonnante
Posté par Sufflope (site web personnel) . Évalué à 5.
Je ne sais pas depuis combien d'années BitKeeper était utilisé, mais si il avait dès le départ étudié les solutions existantes, et poussé au développement (ou à l'amélioration de l'existant) d'un équivalent libre, depuis le temps, on aurait peut-être un outil à côté duquel BitKeeper serait ridicule...
Comme quoi, faut jamais se satisfaire de l'existant si il est pas satisfaisant (lapalissade spotted).
(Bon OK c'est facile pour moi de dire ça, alors que je code rien du tout, je ne suis qu'un utilisateur final... J'essaierai de m'en souvenir si jamais mes études naissantes d'informatique continuent dans la programmation :D )
[^] # Re: Rapidité étonnante
Posté par yoho (site web personnel) . Évalué à 7.
Les gens qui se sont penchés sur git sont certainements les plus brillants de la planète, donc cela ne m'étonnerait pas qu'en quelques mois, ils arrivent au même niveau que BitKeeper, mais c'est toujours du temps en moins qu'ils consacrent au noyau Linux (qui est un pléonasme, mais bon, il est usuel maintenant).
Donc au final, je pense que Linus avait fait un bon choix car les développeurs ont pu se consacrer à l'essentiel. D'ailleurs, il y a de nombreux articles qui disent que BitKeeper a amélioré la vitesse de développement de façon substantielle.
[^] # Re: Rapidité étonnante
Posté par pasBill pasGates . Évalué à 10.
Je me permets d'emettre un fort doute.
Etre un guru du kernel ne fait pas d'un dev un guru de systemes SCM de meme qu'un expert en physique quantique ne devient pas magiquement expert en physique des materiaux.
A mon avis ils sont simplement en train de trouver une solution de rechange temporaire en attendant qu'un des SCM existants ait les fonctionnalites voulues.
[^] # Re: Rapidité étonnante
Posté par Philippe F (site web personnel) . Évalué à 10.
Si tu regardes git, ca ne resemble a aucun gestionnaire de source existant (peut-etre arch ?), donc visiblement, on n'aurait pas pu le faire en faisant evoluer CVS.
Linus se concentre probablement sur les fonctionnalites qui lui paraissent les plus essentielles dans un gestionnaire de conf pour gerer les sources du noyau.
Il a aussi l'experience de bitkeeper pour savoir ce qu'on peut faire, ce qui l'interesse lui, ce dont le kernel a besoin maintenant, etc etc.
Son truc pour l'instant n'a pas l'air d'avoir beaucoup de points communs avec bitkeeper.
[^] # Re: Rapidité étonnante
Posté par mykey . Évalué à 5.
Finalement on se trouve dans une bonne situation pour développer un logiciel libre qui risque d'être fort agréable.
[^] # Re: Rapidité étonnante
Posté par Mathias Bavay (site web personnel) . Évalué à 10.
Donc BitKeeper devrait (a mon humble avis) etre consideré comme une source d'inspiration plutot que comme une perte de temps facheuse...
Mathias
[^] # Re: Rapidité étonnante
Posté par abgech . Évalué à 10.
Je pense plutôt que c'est une nouvelle démonstration (si tant est qu'il en fallait encore une) de la supériorité du modèle LL de développement.
Maintenant à la retraite, j'ai passé, simultanément, moitié de ma vie professionelle dans l'industrie et moitié comme enseignant en école d'ingénieurs. Les quelques petites (très petites) réflexions qui suivent me sont venues de cette expérience, je n'ai pas prétention à généraliser.
Dans une entreprise dite "normale", réagir à un problème implique que le niveau compétent pour prendre une décision soit conscient du problème, cela peut prendre pas mal de temps. Ensuite il faut au strict minimum plusieurs séances pour en discuter. De nouveau plusieurs séances pour tenter de trouver une solution. Après quelques semaines (mois, années), une ou plusieurs solutions ayant été déterminées, il faut la/les soumettre à l'échelon supérieur, qui lui-même va le soumettre à l'échelon supérieur (non, ce n'est pas obligatoirement récursif !). Une fois cette cascade ascendante épuisée, une nouvelle cascade se déclenche, descendante celle-là, pour la mise en oeuvre de la solution. Etc. Etc.
Dans l'enseignement, c'est encore pire. Je crois que chaque enseignant connaît les interminables séances de discussions, la plupart du temps parfaitement stériles, sauf, peut-être, que l'on enrichi son vocabulaire avec des mots à la mode.
Il me semble, il m'apparaît que le LL échappe à cette infernale spirale. Composé de développeurs co-décidants, capable de dialoguer rapidement d'un bout du monde à l'autre (au fait, un globe a-t-il un bout ?), le LL est extrèmement réactif.
Sur un plan plus théorique, il y a longtemps que l'on sait que, pour les grand systèmes, les ensembles de systèmes simples interagissants sont beaucoup plus efficaces que les systèmes complexes (ici, toute référence à une architecture de noyau compact ne serait pas obligatoirement une coincidence).
Bonne journée à tous.
# Licence de BitKeeper
Posté par Sébastien Koechlin . Évalué à 4.
Ou alors est-ce la raison pour laquelle il semble que ce ne soit qu'un système de gestion de répertoires ?
[^] # Re: Licence de BitKeeper
Posté par Victor . Évalué à 4.
[^] # Re: Licence de BitKeeper
Posté par Philippe F (site web personnel) . Évalué à 3.
# Et subversion ??
Posté par ciskos . Évalué à -3.
déjà testés à grande échelle ...
dommage de réécrire la roue franchement.
[^] # Re: Et subversion ??
Posté par ouah (site web personnel) . Évalué à 1.
[^] # Re: Et subversion ??
Posté par xeuzuex . Évalué à 1.
Quel est le reel avantage du distribué ?
pour moi il y a bien un moment ou tt le monde doit mettre son travail en commun, donc au moins avoir un referenciel unique ! Si chacun a son repository en local il faut bien le synchroniser avec qq choses ?
[^] # Re: Et subversion ??
Posté par or zax . Évalué à 7.
en distribué tout le monde à son propre dépot, donc tu décide de corriger un bug, en créant une branche dans ton dépot, tu préviens le responsable du projet en lui donnant l'accès, si ça l'intéresse il intègre en fusionnant ta branche dans la branche principale, sinon il fait rien, mais d'autres intéressés pourront l'intégrer pour eux.
De plus ça minimise le nombre de changeset, si il faut 20 changesets pour corriger le bug, dans la fusion de la branche le mainline ajoute un changeset regroupant toute ta branche.
[^] # Re: Et subversion ??
Posté par xeuzuex . Évalué à 1.
Pour moi pas de soucis avec svn ! si chacun travail ds une branche independante ! Meme si celle ci est sur un seul repository ...
Les merges entre differentes branches sont aussi possible !
>De plus ça minimise le nombre de changeset, si il faut 20 changesets pour corriger le bug, dans la fusion de la branche le mainline ajoute un changeset regroupant toute ta branche.
waouh ?
Je vois ce que tu veux dire mais n'est ce pas un comportement svn ?
Les non distribues n'ont pas forcement ce comportement ?
[^] # Re: Et subversion ??
Posté par or zax . Évalué à 2.
De plus plus personne n'a besoin de se connecter au central, sauf pour faire les update de temps en temps :
_ économie d'infrastructure, car quand il faut gérer un grand nombre de contributeur ....
_ gain en sécurité
Pour la gestion des branches c'est identiques en centralisé, le distribué par sa nature te pousse juste à plus les utiliser. Car les branches sont le couteau suisse du distribué, tu fais pratiquement tout en jouant sur les branches, l'outil est accès sur cela
Ce qui me plait c'est le fait qu'il n'y est pas de serveur à installer, c'est rapide.
Donc l'un n'est pas mieux que l'autre, c'est juste une façon de travailler un peu différente.
SVN pour être franc je ne l'utilise pas mais j'ai une excellente opinion dessus sur le fait que je ne lui connais pas de critique parmi ceux qui le test, et le fait qu'il soit centralisé n'étant pas un défaut ...
Donc pour conclure, la question n'est pas ce qu'il est possible de faire ou pas avec l'un et l'autre mais la façon de travailler.
[^] # Re: Et subversion ??
Posté par xeuzuex . Évalué à 1.
De mon cote j'utilise un peu svn qui est effectivement bien pour le dev.
Juste un petit reproche a svn les checkouts dupliquent tous les fichiers sur le poste local. Du coup si tu as 100Mo de binaires ds ton repository le checkout sur ton client va prendre 200Mo.
Vu que le diff sur des binaires n'est pas utile, je trouve ca dommage de prendre ttes cette place !
[^] # Re: Et subversion ??
Posté par Lucas . Évalué à 1.
[^] # Re: Et subversion ??
Posté par Stéphane . Évalué à 5.
http://www.dwheeler.com/essays/scm.html(...)
Voir aussi un texte écrit (encore en anglais) par l'équipe de Subversion, qui explique pourquoi Subversion n'est pas adapté au modele de développement de Linux:
http://subversion.tigris.org/subversion-linus.html(...)
Sinon je pense aussi que la source du "problème" est que l'équipe de dev du Kernel ne souhaite pas changer de manière de travailler..
Après tout ca ne regarde qu'eux, tant que cela n'influence pas la qualité et la sécurité de Linux....
Ce que je trouve domage c'est d'avoir mis de côté SVK (une "extension" décentralisée de Subversion)..
[^] # Re: Et subversion ??
Posté par xeuzuex . Évalué à 1.
On devrait pouvoir avoir le choix mode centralise ou non , juste en changeant la conf par projet
[^] # Re: Et subversion ??
Posté par or zax . Évalué à 1.
[^] # Re: Et subversion ??
Posté par tgl . Évalué à 4.
Tu trouveras des éléments de réponses de la bouche des devs de Subversion ici :
http://subversion.tigris.org/subversion-linus.html(...)
# Viva linuxa fr-a
Posté par Christophe Fergeau . Évalué à 10.
Pour ceux qui pensent que linus est un génie parce qu'il a réécrit bitkeeper en 2 lignes de code et que les gars d'arch et subversion et tout ça sont des gros nuls parce qu'en qques années ils ont pas été foutus de faire la même chose, pour ceux qui pensent que linus est un idiot de refait son propre scm alors qu'il pourrait contribuer à d'autres projets, ... Bref, pour tous ceux qui pensent que git est un scm, je me permets de citer un mail de linus (récupéré sur http://kerneltrap.org/node/4982(...) qui est cité dans un commentaire précédent, mais le linuxfrien moyen n'est pas capable de lire avant d'ouvrir sa gueule, et probablement encore moins de comprendre ce qu'il lit quand par miracle il le fait) :
« Anyway, the reason I can do it quickly is that my scripts will _not_ be an SCM, they'll be a very specific "log Linus' state" kind of thing. That will make the linear patch merge a lot more time-efficient, and thus possible. »
# [OT] 1 + 1 = 1
Posté par Bertrand D . Évalué à 3.
Ok, je connais le chemin ----> [ ]
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.