Ce week-end, deux développeurs du noyau ont réussi chacun de leur côté à importer la totalité de l'historique du noyau dans Git, l'un à partir de CVS, l'autre à partir de BitKeeper. Ces trois ans d'historique représentaient 3.2 Go de données une fois importées dans Git, ce qui pour Linus Torvalds est tout à fait raisonnable et conforme à ses prédictions.
Toutefois, Linus a proposé de ne pas importer tout l'historique dans Git, mais de repartir de zéro. Cette proposition n'a pas rencontré d'opposition et le développement du noyau a donc repris en utilisant Git. Depuis, plusieurs dizaines de patches ont été intégrés, aboutissant à la sortie de la version 2.6.12-rc3 du noyau. Cette version est la première utilisant le nouveau système de gestion des sources Git.
Par ailleurs, Tony Luck a annoncé qu'il avait rédigé un guide pour les débutants de Git et des développeurs ont annoncé l'existence de deux interfaces Web pour Git : gitweb et wit.
Face au changement de politique de la société BitMover, il est intéressant de constater la vitesse à laquelle l'équipe de développement du noyau a créé un nouvel outil et l'a rendu utilisable pour continuer le travail et sortir de nouvelles versions.
Aller plus loin
- KernelTrap: Linux: 2.6.12-rc3, First "git" Kernel Release (4 clics)
- KernelTrap: Linux: Importing The Kernel Into git, Merging (3 clics)
- KernelTrap: Linux: Beginner's Guide To Git (8 clics)
- KernelTrap: Linux: Git Web Interfaces (3 clics)
- DLFP: BitKeeper : plus de version gratuite (5 clics)
- DLFP: Linus développe un remplaçant original à BitKeeper (18 clics)
# BK vs git.
Posté par chl (site web personnel) . Évalué à 10.
Oui c'est interessant, mais BK est a des années lumiere de git. Faut pas non plus croire qu'on developpe un outil avec autant de features que BK, comme ça en 3 semaines, meme avec les meilleurs developpeurs du monde.
[^] # Re: BK vs git.
Posté par zeb . Évalué à 3.
[^] # Re: BK vs git.
Posté par Boa Treize (site web personnel) . Évalué à 8.
On peut aussi se dire que l'utilisation d'un logiciel proprio a explicitement motivé plusieurs projets (notamment GNU Arch), et que sans ça on aurait pas eu toute cette palette de nouveaux outils qui arrivent à maturité en ce moment.
[^] # Re: BK vs git.
Posté par chl (site web personnel) . Évalué à 5.
Je ne suis pas d'accord. Linus avait recherché, il y a 3 ans, des solutions mais aucune ne lui convenait. 3 ans apres, il a encore recherché mais la encore aucune solution ne convenait non plus. Ses besoins sont specifiques, et il a donc developpé un outil qui y repondait.
[^] # Re: BK vs git.
Posté par zeb . Évalué à -1.
Non, il a pris un outil proprio qui a ete developpe en fonction de ses besoins, avec une license absolument inacceptable (clause de non-concurrence).
C'est vrai qu'il y a 3 ans les outils n'etaient pas la. Mais aujourd'hui, ils le sont, puisque "Git" a ete juge acceptable pour la production. Il n'est peut-etre pas au niveau de BK, mais ca m'etonnerait que cela dure longtemps.
Encore une fois, McVoy a beaucoup a perdre. Il a bien profite de la pub que le developpement du noyau Linux lui a faite, et maintenant il se retrouve avec un concurrent libre sur le marche. Pas une tres bonne manoeuvre, finalement.
[^] # Re: BK vs git.
Posté par Khâpin (site web personnel) . Évalué à 3.
Il parlait de git... essaye de lire les commentaires en entier avant de t'enflammer!
[^] # Re: BK vs git.
Posté par zeb . Évalué à 6.
Mais ca va justement dans le meme sens. Git n'a pas mis bien longtemps a etre developpe. Ce qui a ete fait aujourd'hui aurait pu etre fait il y a trois ans, quand ceux qui se sont faits traiter "d'integristes" l'avaient mis en garde contre l'adoption de BK.
[^] # Re: BK vs git.
Posté par Khâpin (site web personnel) . Évalué à -2.
[^] # Re: BK vs git.
Posté par Philippe F (site web personnel) . Évalué à 6.
D'un autre cote, elle a surement permis a Linus de se fixer les idees sur ce qu'il voulait dans un SCM (et pas un CMS, vive les acronymes). Avant bitkeeper, il n'en avait pas trouve qui lui convienne et il n'aurait probablement pu en pondre un aussi vite.
Linus a aussi eu l'habitude de travailler pendant tres longtemps avec des outils tres simples: patch, diff, et le mail pour stocker les patches en cours. Je soupconne que s'il n'avait pas eu un outil tres sophistique pendant quelques temps, il aurait continue avec sa methode a lui qui marchait tres bien, c'est a dire a la mano. Evidemment, on peut tout supposer mais de mon point de vue, l'utilisation de bitkeeper a engendre git et ce dernier n'aurait pas vu le jour sans cette periode de transition.
[^] # Re: BK vs git.
Posté par Christophe Lucas (site web personnel) . Évalué à 5.
Face au changement de politique de la société BitMover, il est intéressant de constater la vitesse à laquelle l'équipe de développement du noyau a créé un nouvel outil et l'a rendu utilisable pour continuer le travail et sortir de nouvelles versions.
Oui c'est interessant, mais BK est a des années lumiere de git. Faut pas non plus croire qu'on developpe un outil avec autant de features que BK, comme ça en 3 semaines, meme avec les meilleurs developpeurs du monde.
Euh je ferais juste une petite remarque : git n'est pas à l'heure actuelle un SCM, alors comparer des choses qui ne peuvent l'être n'a aucun sens. Donc dire : BK vs git est infondé. git est une bonne base pour développer un SCM, voilà tout.
Cf : http://lwn.net/Articles/130865/(...)
Bonne journée,
# A pas mesurés
Posté par Guillaume POIRIER . Évalué à 5.
Les progrès se font donc à pas mesurés. Pour le moment, les fusions de branches de dévelloppement n'ont été testés que dans des cas simple, où il n'y a pas de conflit.
Là où BitKeeper excelle, il me semble, c'est en ce qui concerne la fusion plus problématique de branches entre les développeurs.
Ne nous entousasmions donc pas trop vite, le plus dure reste à venir... mais c'est clair que vu la vitesse à laquelle progresse git, je ne serais pas étonné qu'ils arrivent à relever le défit bien vite...
D'ailleurs en passant, sur la même page, on peut voir:
Un beau pied de nez à tous ceux qui ont décrié le nouveau mode de développement du kernel Linux.
Il permet bel et bien d'intégrer des avancées technologiques bien plus vite que par le passé.
... maintenant, qu'en est-il au niveau stabilité, j'en sais trop rien, mais chez moi, ça marche (TM).
[^] # Re: A pas mesurés
Posté par lezardbreton . Évalué à 3.
Il permet bel et bien d'intégrer des avancées technologiques bien plus vite que par le passé.
... maintenant, qu'en est-il au niveau stabilité, j'en sais trop rien, mais chez moi, ça marche (TM).
Il ne me semble pas avoir lu quelqu'un dire que le nouveau mode de développement rendrait plus difficile l'innovation. Par contre, j'ai lu de nombreuses critiques montrant du doigt l'incapacité à sortir de vraies releases stables (ce qui a été amélioré avec l'apparition des releases de correction mineures en W.X.Y.Z).
# git, un outil de bas niveau
Posté par Boa Treize (site web personnel) . Évalué à 10.
git est un outil de bas niveau, simple et très performant, qui a pour but de gérer l'évolution du contenu d'une arborescence. Il gère en gros trois types d'objets de manière très rapide, caractérisés par leur somme de contrôle SHA-1 : des blobs (fichiers de base), des arbres (listes de blobs et d'arbres) et des commit (un arbre correspondant à une version donnée, et liste des commits précédents ayant permis d'en arriver là). Il gère par ailleurs un index, afin d'accélerer le travail sur un arbre voulu. Il permet quelques opérations en plus (affichage du contenu d'un blob à un moment donné, fusion simple d'arbres), et c'est tout. On est très loin des autres systèmes en termes de fonctionnalités (mais Linus n'a pas besoin de tout), et très en avance en termes de performance (car Linus en a bien besoin).
Et voilà et c'est tout et c'est déjà pas mal. C'est suffisant pour bosser (avec plein de scripts autour pour automatiser, je suppose) en attendant que d'autres solutions deviennent plus matures, ou que git lui-même évolue encore plus.
Le truc intéressant au niveau des performances, c'est que du coup les gestionnaires de version qui n'utilisent pas de base de données (Arch, Darcs) sont très intéressés par se servir de git sous le capot pour le stockage des fichiers, tout en offrant leurs fonctionnalités plus évoluées.
Bref, la gestion de source dans le monde du libre, qui avait déjà pas mal évolué ces dernières années et ces derniers mois, s'est encore pris un coup d'accélérateur grâce à git. Finalement, BitKeeper aura pas mal fait bouger les choses, quitte à être le bâton plus que la carotte. :-)
[^] # Re: git, un outil de bas niveau
Posté par salvaire . Évalué à 2.
J'ai lu que Git est une sorte de système de fichier loopback. Quelqu'un a t'il plus d'infos?
[^] # Re: git, un outil de bas niveau
Posté par Boa Treize (site web personnel) . Évalué à 4.
Pour créer un diff, il suffit de regarder les deux commit, voir dans les arbres correspondants si le fichier a changé, et si oui, appeler la bonne vieille commande diff avec les deux fichiers à comparer.
Pour appliquer un diff, il suffit d'extraire la version voulue (a priori la plus récente), d'utiliser patch, et de stocker la nouvelle version créée.
Quant à savoir ce que c'est qu'un patch au sens rcs ou un système de fichier loopback (à tes souhaits)... Pas la moindre idée.
[^] # Re: git, un outil de bas niveau
Posté par M . Évalué à 3.
perdu, il stocke chaque nouvelle version, c'est pour ca que l'import BK etait aussi gros...
[^] # Re: git, un outil de bas niveau
Posté par M . Évalué à 3.
Le probleme c'est que git n'est pas rellement portable et s'appuie quand meme pas mal sur le VFS du noyau (cache, ...) et de certaines astuces (lire les fichiers dans l'ordre des inodes) qui ne sont pas toujours vraie partout.
[^] # Re: git, un outil de bas niveau
Posté par zeb . Évalué à 3.
C'est officiellement annonce pour Arch:
http://lists.seyza.com/pipermail/gnu-arch-dev/2005-April/001097.htm(...)
C'est de tres bonne augure pour Git, qui va surement se retrouver propulse.
[^] # Re: git, un outil de bas niveau
Posté par salvaire . Évalué à 2.
http://www.seyza.com/=clients/linus/tree/index.html(...)
Est il possible de ne pas stocker les données sous forme incrémentale (pour compresser la taille)? Peut être est ce seulement pour le cache.
# Torvalds vs Tridgell
Posté par zeb . Évalué à 4.
http://www.theregister.co.uk/2005/04/14/torvalds_attacks_tridgell/(...)
http://www.theregister.co.uk/2005/04/21/tridgell_bitkeeper_howto/(...)
et une reponse de Perens a Torvalds qui lui demande de calmer le jeu.
http://www.theregister.co.uk/2005/04/15/perens_on_torvalds/(...)
En effet, le "crime" pretendument effectue par Tridgell ne serait en fait qu'une simple analyse de la facon dont BK enregistrait les donnees sur le disque, et en aucun cas une vraie operation de reverse engineering sur le soft lui-meme. En d'autres termes, les reproches seraient plus du FUD qu'autre chose.
Perens d'ailleurs rappelle a Linus que c'est lui qui a impose un CMS proprio a la communaute sans ecouter les critiques, et que par consequent il a une part de responsabilite dans ce qui s'est passe. D'autant que ce scenario avait justement ete decrit par les detracteurs de la solution BK.
[^] # Re: Torvalds vs Tridgell
Posté par Boa Treize (site web personnel) . Évalué à 3.
Torvalds (qui n'est pas un saint) n'a clairement pas été content de la « faute » de Tridgell et n'a pas mâché ses mots sur le moment. Celui-ci en dit le moins possible, un comportement recommandé par son avocat, et qui dans le contexte me semble raisonnable. Ceci dit, même si je comprends une part de l'énervement de Linus (paf, obligé de laisser tomber le meilleur outil du monde créé exprès pour lui ou presque), je pense comme beaucoup d'autres que c'est surtout l'auteur de BitKeeper, le sanguin et volubile Larry McVoy, qui est à blâmer avec ses licences encore plus débiles que celles de Microsoft, et sa volonté de les appliquer. (Larry McVoy qui n'est par ailleurs pas le dernier des cons, parce que BitKeeper, techniquement parlant, ça a l'air de bien roxer.) Pour ce que j'en sais, Trigdell était dans son bon droit, éthiquement à coup sûr, légalement je l'espère aussi.
Enfin bref, je pense que globalement cette « affaire BitKeeper » a fait plus de bien (accélération du développement du noyau, accélération des solutions libres concurrentes) que de mal (grinçages de dents des plus libristes, potentielle « affaire Tridgell »).
[^] # Re: Torvalds vs Tridgell
Posté par zeb . Évalué à 4.
Oui. Pour autant les arguments de Perens sont tres clairs et tres pertinents: McVoy pretend que les meta-donnees creees par BK sont soumises a la license de BK, ce qui est aussi absurde que de dire qu'un logiciel compile avec gcc est "contamine" par la GPL. D'autre part, la license de BK interdit qu'on l'utilise pour creer un concurrent de BK. Quand MS fait ca, on crie au scandale. Pourtant, c'est la license d'un logiciel qui a permis le developpement du noyau pendant 2 ans.
Bref, finalement avec 2 ans de retard, il est arrive ce qui arriva: l'utilisation d'un CMS libre. Si Linus avait decide cela des le depart, Git en aurait probablement beneficie et n'aurait pas ses limitations actuelles. On verra dans deux ans a quoi ressemble Git, et probablement sera aussi bien sinon meilleur que BK. D'ailleurs, McVoy a beaucoup a perdre dans cette histoire: il y a maintenant un conurrent de BK libre qui va surement evoluer tres rapidement.
[^] # Re: Torvalds vs Tridgell
Posté par Antoine Reilles (site web personnel) . Évalué à 5.
En fait, ce n'est pas si absurde que ça, dans le cas de systèmes comme bison, mais aussi automake ou autoconf par exemple, ou une partie du code généré est directement issu de squelettes qui eux sont sous GPL.
Il y a d'ailleurs explicitement dans les licences de gcc, autoconf et autres une mension pour éviter cette "contamination" du code produit par l'outil.
http://lists.gnu.org/archive/html/bison-patches/2003-09/msg00005.html
et l'extrait :
# Copyright 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001, 2002
# Free Software Foundation, Inc.
# This configure script is free software; the Free Software Foundation
# gives unlimited permission to copy, distribute and modify it.
[^] # Re: Torvalds vs Tridgell
Posté par zeb . Évalué à 4.
Pour faire une autre analogie plus pertinente, est-ce qu'une image peinte avec Gimp est libre ? Ou bien un texte ecrit dans OpenOffice (avec des fontes dans le domaine public, puisque les fontes GPL apparemment posent aussi un probleme, arf :) ?
[^] # Re: Torvalds vs Tridgell
Posté par M . Évalué à 3.
[^] # Re: Torvalds vs Tridgell
Posté par Antoine Reilles (site web personnel) . Évalué à 2.
http://www.fsf.org/licensing/licenses/gpl-faq.html#CanIUseGPLToolsF(...)
explique en quoi il a fallu faire des ajouts à la licence pour éviter ce genre de problèmes.
En particulier, ça peux géner les gens qui font du code propriétaire, mais aussi ceux que veulent utiliser des licences du genre BSD ou MIT (et oui, il n'y a pas d'équivalent à la toolchain GNU sous licence BSD)
[^] # Re: Torvalds vs Tridgell
Posté par zeb . Évalué à 6.
Ce que Perens reproche, c'est que Tridgell est considere comme un heros quand il ecoute un reseau MS pour developer Samba, mais un salaud quand il fait ca avec BK. Alors que ce n'est pas la different.
# Tracabilité
Posté par ckyl . Évalué à 5.
J'ai toujours eu un problème avec Linux c'est le manque de tracabilité du code dans le temps. BK à permis d'assurer cela pour la période ou il a été en fonction mais apparement on repart de 0.
Il est très interessant quand on s'interesse à un sous système ou un bout de code de pouvoir avoir l'historique depuis l'import de celui-ci. Cela permet entre autre de comprendre pourquoi et comment telle ou telle chose à été faite. De vérifier depuis combien de temps une fonctionalité est dispo etc.
Repartir à chaque fois de 0 me semble abérrant. Et j'espere qu'à partir de Git tout le monde pourra avoir accès à des informations aussi basiques...
Note: a l'heure qu'il est linux.bkbits.net ne répond pas :-)
[^] # Re: Tracabilité
Posté par Boa Treize (site web personnel) . Évalué à 7.
Houla, faut pas comprendre ça de travers ! C'est pas comme si Linus avait effacé tout l'historique, ou qu'il s'en foutait. Simplement, il trouve (et tous les autres devs trouvent) que mettre 3,2 Go de données dans un système vieux d'à peine quelques semaines, c'est trop lourd. Ça imposerait que chaque personne voulant utiliser git pour envoyer des patches à Linus devrait télécharger ces 3,2 Go. Merci la bande passante et les resources des serveurs ! Ça ne servirait pas à grand chose, car il n'y a pas encore d'outils pour explorer confortablement l'historique.
Bref, après avoir vérifié que tout l'historique était bien récupérable des dépôts BitKeeper et CVS, et qu'ils pouvaient facilement mettre l'historique dans un git, les développeurs ont décidé de repousser à plus tard la création d'une archive intégrant le tout, et de travailler avec des dépôts pour l'instant plus légers.
[^] # Re: Tracabilité
Posté par Vivi (site web personnel) . Évalué à 4.
Mais si, ça arrive :)
http://marc.theaimsgroup.com/?l=git&m=111376732010640&w=2(...)
[^] # Re: Tracabilité
Posté par Philippe F (site web personnel) . Évalué à 2.
En attendant, ca reste un peu stressant comme situation, ce ne pas avoir l'historique.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.