J'ai un peu suivi l'evolution du developpement de GIT sur la LKML... et de mon point de vue, je crois que 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. 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 Edouard Gomez . En réponse à la dépêche Linus développe un remplaçant original à BitKeeper. É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.