samedi 11 octobre
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Liens connexes

Dépêche modérée par

Dépêche éditée par

: Le développement du noyau continue autour de Git

Posté par Thomas Petazzoni (page perso, ). Modéré le 21 avril 2005.
0
Suite à l'annonce de l'arrêt de la version gratuite de BitKeeper, Linus Torvalds et quelques autres développeurs ont travaillé sur un nouveau système pour gérer le développement du noyau, appelé Git.

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.

> Lire les commentaires (31 commentaires, moyenne: 4,1).  

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.

BK vs git.

Posté par chl (page perso, ) le 21/04/2005 à 14:10. (lien). Évalué à 10.

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.

A pas mesurés

Posté par Guillaume POIRIER (page perso, ) le 21/04/2005 à 14:17. (lien). Évalué à 5.

Depuis l'article de Kerneltrap:

He then successfully received a merge from arm maintainer Russell King [interview], with a comment stating, "first ever true git merge. Let's see if it actually works." The merge was a simple one as there were no file conflicts, but as a first step it helped to prove the concepts.

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:
after a planned merge of the SCSI development branch following the upcoming release of 2.6.12, "Linux will have more advanced Fibre Channel support than any currently available operating system."

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).

git, un outil de bas niveau

Posté par Boa Treize (page perso, ) le 21/04/2005 à 14:32. (lien). Évalué à 10.

Avant que tout le monde (enfin, sauf les deux commentaires précédents) n'imagine que Linus a fait mieux que BitKeeper (et Subversion, Arch, Darcs, Monotone, etc.) en deux semaines, voici quelques précisions sur git.

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. :-)

Torvalds vs Tridgell

Posté par zeb () le 21/04/2005 à 14:46. (lien). Évalué à 4.

A ce propos, il y a une serie d'articles sur The Register sur la crise entre Torvalds et Tridgell, Torvalds l'ayant proprement "assassine":
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.

Tracabilité

Posté par cykl (Jabber id, ) le 21/04/2005 à 16:52. (lien). Évalué à 5.

> Toutefois, Linus a proposé de ne pas importer tout l'historique dans Git, mais de repartir de zéro.

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 :-)

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.119s (dont 0.0105 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !