Articles précédents : Développeur
- [19] GUADEC 2005 : Stuttgart, 29-31 mai
- [169] BitKeeper : plus de version gratuite
- [11] Coding Party AlternC
- [24] Sortie sous Creative Commons Share-Alike de Linux Device Drivers 3ème édition
- [0] 2LE publie son framework Castor web builder
- [66] JUnitScenario 0.1 vient de sortir
- [5] OSF DCE 1.2 passe sous licence LGPL
- [71] Améliorer les performances du noyau avec un algorithme génétique
- [33] phpJaz, un framework léger pour PHP
- [14] Les 3 heures du PHP
Liens connexes
- Le README de Git (2436 hits)
- "Incoming", le mail de Andrew Morton (1377 hits)
- DLFP: Bitkeeper: plus de version gratuite (1323 hits)
Dépêche modérée par
Dépêche éditée par
Développeur : Linus développe un remplaçant original à BitKeeper
Posté par Colin Leroy (page perso, ). Modéré le 12 avril 2005.
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.
![[en]](../../../images/en.png)
Le README de Git (2436 hits)-
"Incoming", le mail de Andrew Morton (1377 hits)
![[fr]](../../../images/fr.png)
DLFP: Bitkeeper: plus de version gratuite (1323 hits)
> Lire la dépêche (77 commentaires, moyenne: 4).
précisions ?
Quelqu'un peut préciser la différence entre "content tracker" et "SCM" ?
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 () le 12/04/2005 à 17:17. (lien). Évalué à 6.Pareil, j'ai à peu près compris le README de Git, par contre je ne vois
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 () le 12/04/2005 à 17:25. (lien). Évalué à 8.Pour ceux qui sont intéressés par le source:
http://www.kernel.org/pub/linux/kernel/people/torvalds/(...)
La dernière version est la 0.04.-
[^]Re: Source
Posté par wismerhill (page perso, ) le 12/04/2005 à 17:53. (lien). Évalué à 6.J'imagine que la prochaine sera la 0.99 ;-)
-
[^]Re: Source
Posté par let antibarbie = xp <- xp - 1 (page perso, ) le 13/04/2005 à 07:22. (lien). Évalué à 6."En seulement une semaine il a déjà développé un outil de remplaçement à BitKeeper" on pourrait presque lire sur cet article... A mon avis il a fait un petit hack dans son coin, et il lance un projet de substitution ... c'est un projet ambitieux en tout cas, car un outil de gestion de sources, c'est pour le moins compliqué à réaliser !
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 () le 13/04/2005 à 15:02. (lien). Évalué à 2.Sans trop trop troller, je ne suis pas sûr que lancer un nouveau SCM libre soit une bonne solution pour améliorer la maturité des SCM libres. Quelque soit les qualités de git, il va se passe énormément de temps entre la 1.0 en ligne de commande & l'apparition de GUI ou de plugins pour l'intégration avec les outils de développement. Il suffit de regarder des outils comme Subversion, arch ou SVK pour voir le temps qu'il faut.
-
-
-
-
-
[^]Re: précisions ?
Posté par bmc () le 12/04/2005 à 17:52. (lien). Évalué à 10.J'avoue que ça a l'air plutôt ambigu... GIT est à la base un Directory Content Manager (DCM), pas vraiment un SCM. Cela signifie qu'à l'origine le but de git n'est pas de gérer les problématiques de patch ou diff entre deux versions de fichiers (ce que fait un SCM), mais uniquement être capable de dire quels fichiers ont été modifiés dans un répertoire.
Voilà ce que j'en ai compris. Les corrections sont les bienvenues :)
-
[^]Re: précisions ?
Posté par Colin Leroy (page perso, ) le 13/04/2005 à 06:40. (lien). Évalué à 6.D'après ce que j'ai compris, git ne fait pas de réseau (contrairement à CVS, BK, ou d'autres), mais permet de merger rapidement des patches de différentes sources - qui sont donc reçus par mail, je crois.
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 () le 13/04/2005 à 18:23. (lien). Évalué à -4.D'après ce que j'ai compris, git ne fait pas de réseau (contrairement à CVS, BK, ou d'autres), mais permet de merger rapidement des patches de différentes sources - qui sont donc reçus par mail, je crois.
ç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.
+--
moué...
-
L'info sur kerneltrap
http://kerneltrap.org/node/4982(...)
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 (page perso, ) le 12/04/2005 à 22:26. (lien). Évalué à 10.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 Frederick Ros (page perso, ) le 13/04/2005 à 06:40. (lien). Évalué à 7.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".
Je suis assez d'accord avec toi ... Le syndrome du "Not invented here" ?
-
[^]Re: L'info sur kerneltrap
Posté par Laurent J (page perso, ) le 13/04/2005 à 06:54. (lien). Évalué à 8.Linus s'embarque dans un choix qui risque d'engendrer un outil purement dédié à SES besoins et à rien d'autre
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 (page perso, ) le 13/04/2005 à 07:01. (lien). Évalué à 2.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.
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 () le 13/04/2005 à 07:19. (lien). Évalué à 10.D'apres la mailing list du kernel, Linus a discuté de ses besoins avec les développeurs de monotone.
Et dans le Changelog de la dernière version de monotone (0.18) sortie le 10, on peut lire:
most operations sped up by a factor of 2 or better; many sped up
by up several orders of magnitude.
- special thanks to Matt Johnston , Derek
Scherger , Linus Torvalds.
mes 0.02¤-
[^]Re: L'info sur kerneltrap
Posté par Frederick Ros (page perso, ) le 13/04/2005 à 09:33. (lien). Évalué à 3.Alors pourquoi ne pas l'utiliser ?
-
[^]Re: L'info sur kerneltrap
Posté par Silence (page perso, ) le 13/04/2005 à 10:37. (lien). Évalué à 1.Ils ont gagnés un facteur de 2, mais bon l'eternité deux fois plus courte... ;^)
je disparais ---> *pouf*--
^d^c-
[^]Re: L'info sur kerneltrap
Posté par Sylvain Sauvage () le 13/04/2005 à 20:09. (lien). Évalué à 2.« L'éternité c'est long, surtout vers la fin ».
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 (page perso, ) le 13/04/2005 à 08:03. (lien). Évalué à 4.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 ,,,
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 (page perso, ) le 13/04/2005 à 09:32. (lien). É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 (page perso, ) le 13/04/2005 à 08:07. (lien). Évalué à -4.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.
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 (Jabber id, page perso, ) le 13/04/2005 à 08:25. (lien). Évalué à 9.Il a fait plusieurs appels sur la ml pour demander à ce que les autres développeurs testent le maximum de SCM et fassent de commentaires, que lui n'aurait pas le temps de les étudier tous. Mais très peu l'ont fait, et à chaque fois pour dire que ce n'était pas au point pour le moment (monotone et darcs trop lents, arch c'est fait déscendre en flêche, bazaar-ng pas prêt, svn pas fait pour ça, et les autres aucun commentaire)...
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 () le 13/04/2005 à 09:33. (lien). Évalué à 3.Tom LORD, l'auteur de Arch/tla à envoyé une lettre personnelle expliquant le principe, les objectifs, et les possibilités de Arch.
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 () le 13/04/2005 à 11:25. (lien). Évalué à 4.De l'avis général, Arch ne correspond pas à ce que les développeurs de Linux (dont le fameux Linus Torvalds, sans "h" et avec un "s") désirent.
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 () le 13/04/2005 à 12:09. (lien). Évalué à 1.tout à fait.
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 () le 13/04/2005 à 08:27. (lien). Évalué à 6.Pas très démocratique tout cela...
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
-
-
[^]Re: L'info sur kerneltrap
Posté par fmaz fmaz () le 13/04/2005 à 09:25. (lien). Évalué à 4.J'ai une question.
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 () le 13/04/2005 à 11:25. (lien). Évalué à 2.> 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?
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 (page perso, ) le 14/04/2005 à 12:11. (lien). Évalué à 0.En fait, Linus utilise la version payante de BitKeeper, non ?
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 (Jabber id, page perso, ) le 14/04/2005 à 13:14. (lien). Évalué à 1.J'ai cru comprendre que non, que les commits (qui passent par un serveur central pour la version libres) ne passeront plus dans quelques temps.
-
-
-
[^]Re: L'info sur kerneltrap
Posté par Vincent Danjean () le 13/04/2005 à 11:29. (lien). Évalué à 2.Le serveur openloging fermera le 1er juillet. A cette date, le client libre fournit par BitMover permettra encore de récupérer les données et méta-données, mais aucun nouveau commit ne sera possible. Pour cela, il faudra utiliser une version payante de BK.
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 () le 14/04/2005 à 06:29. (lien). Évalué à 2.Tiens, toi zici!
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 (page perso, ) le 14/04/2005 à 12:13. (lien). Évalué à 1.C'est uniquement le cas d'une version *libre* (entendez ici libre pas très libre) qui pour l'utiliser nécessite un *login* sur le serveur de chez BitMover.
-
[^]Re: L'info sur kerneltrap
-
-
-
-
-
-
[^]Re: L'info sur kerneltrap
Posté par Thierry (page perso, ) le 13/04/2005 à 07:04. (lien). Évalué à 5.un choix qui risque d'engendrer un outil purement dédié à SES besoins et à rien d'autre.
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 (page perso, ) le 13/04/2005 à 09:36. (lien). Évalué à 2.Et tu fais quoi des contributeurs .. Si chacun avait fait ce que Linus est en train de faire, on n'aurait certainement XXX OS libres non-finalises ...
-
[^]Re: L'info sur kerneltrap
Posté par ragoutoutou () le 13/04/2005 à 09:48. (lien). Évalué à 4.Si on voulait démocratiser ce processus, il faudrait:
- 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 (page perso, ) le 13/04/2005 à 10:53. (lien). Évalué à 3.non, car, aussi compliqué soit-il, un projet de SCM n'a pas vraiment l'envergure de celui d'un OS vois tu. Il est donc plus aisé de repartir à 0 pour un SCM que pour un OS.
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 () le 13/04/2005 à 11:19. (lien). Évalué à 2.Réflexion à court terme : autant s'investir dans un projet existant prend du temps, autant en maintenir un nouveau en bouffe.
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 () le 13/04/2005 à 12:10. (lien). Évalué à 1.Je pense surtout que Linus sait ce qu'il veut après avoir utilisé bitkeeper... utiliser une application quotidiennement et la critiquer est le meilleur moyen pour savoir ce dont on a besoin et ce dont on a pas besoin... Il peut se permettre maintenant d'aller droit au but sans se perdre dans des choses inutiles... Et puis bon, c'est loin d'être une bille en programmation, ni en gestion de projet... il faut lui faire confiance.
-
[^]Re: L'info sur kerneltrap
Posté par Philippe Fremy (page perso, ) le 13/04/2005 à 17:21. (lien). Évalué à 4.A lire le resume sur kerneltrap, la contrainte no 1 est le temps qu'il faut pour appliquer un jeu de changement. Il a evalue tous les SCM et a chaque fois, il semble que cela ait ete le point bloquant.
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 () le 13/04/2005 à 19:39. (lien). Évalué à 2.Si tu veux une democratie...
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 zero heure (Jabber id, page perso, ) le 13/04/2005 à 07:44. (lien). Évalué à 7.Linus s'embarque dans un choix qui risque d'engendrer un outil purement dédié à SES besoins et à rien d'autre
ç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.--
J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm-
[^]Re: L'info sur kerneltrap
Posté par Edouard Gomez (page perso, ) le 13/04/2005 à 12:03. (lien). Évalué à 4.>Enfin j'ai du mal à croire que Linus soit un imbécile pas pragmatique du tout.
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 Fremy (page perso, ) le 13/04/2005 à 17:28. (lien). Évalué à 5.> Or aujourd'hui bizarrement, GIT ca va lui convenir
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 () le 13/04/2005 à 18:40. (lien). Évalué à 5.> 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 ?
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 zero heure (Jabber id, page perso, ) le 13/04/2005 à 17:37. (lien). Évalué à 2.je sais bien que tu n'as pas traité Linus d'imbécile et que c'est un raccourci (audacieux) de ma part. Je crois bien avoir plussé ton commentaire d'ailleurs. Mais on pourrait y comprendre que Linus n'a pas réfléchi beaucoup:
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.--
J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm-
[^]Re: L'info sur kerneltrap
Posté par zero heure (Jabber id, page perso, ) le 13/04/2005 à 17:57. (lien). Évalué à 5.j'oubliais: on a tous fait ça.
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!--
J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm
-
-
[^]Re: L'info sur kerneltrap
Posté par Olivier Jeannet () le 14/04/2005 à 12:05. (lien). Évalué à 4.il n'y avait pas de noyau Unix-like tournant sur le i386 que Linus utilisait. Minix [...]. Et a l'epoque 386BSD n'existait pas si je me trompe pas.
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 (page perso, ) le 13/04/2005 à 12:01. (lien). Évalué à 10.Il a à peine évoquer les raisons qui l'ont poussé à rejeter Monotone.
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 () le 13/04/2005 à 21:26. (lien). Évalué à 3.Merci pour ton retour d'expérience au sujet de tla.
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
Quand on voit qu'en moins d'une semaine le remplaçant est déjà prêt à être testé (bon OK ça veut pas dire qu'il est prêt et aussi bien, mais quand même), c'est à se demander pourquoi Linus a choisi BitKeeper au lieu de faire ça tout de suite...
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 (page perso, ) le 12/04/2005 à 18:18. (lien). Évalué à 7.Oui, mais bon, le remplaçant a certainement moins de fonctionalités (pour l'instant) que BitKeeper, il faut pas s'emballer.
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 () le 13/04/2005 à 01:34. (lien). Évalué à 10.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).
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 Fremy (page perso, ) le 12/04/2005 à 19:04. (lien). Évalué à 10.Bitkeeper et git n'ont pas du tout le meme objectif, ni le meme jeu de fonctionnalite.
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 () le 12/04/2005 à 19:07. (lien). Évalué à 5.Je pense que le développement d'un tel logiciel aurait été long (manque de développeur) mais réussit. Maintenant qu'on est devant une impasse (plus de SCM puissant et gratuit) un tel développement pourra acquérir une plus grande quantité de développeurs, donc plus de suivies et de rapports de bugs.
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 (page perso, ) le 12/04/2005 à 22:38. (lien). Évalué à 10.Je pense qu'il ne faut pas faire le raisonnement "si Linus avait choisit de developper son propre concurent de BitKeeper des le debut, cela aurait simplifié les choses". En effet, d'apres ce qu'en dit Linus, l'UTILISATION de BitKeeper a fait changer les mentalitees, a apporte de nouveaux modes de fonctionnement et fait emerger la prise de conscience d'un besoin. Sans BitKeeper, le noyau serait peut etre toujours developpé avec CVS, et personne n'aurait realisé que ce n'est pas optimum...
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 () le 13/04/2005 à 06:30. (lien). Évalué à 10.Étonnante ? Vraiment ?
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.--
Il est démocratiquement impensable, qu'en république, il y ait trop de gens qui se foutent royalement de tout -- Pierre Dac
Licence de BitKeeper
Il y a une chose que je ne comprends pas, il me semblait que la license de bitkeeper interdisait justement à toute personne qui utilisait la version gratuite de travailler sur la conception ou la programmation un mécanisme de gestion des sources pendant un certain temps.
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 kaouete (page perso, ) le 12/04/2005 à 23:00. (lien). Évalué à 4.Il faut comprendre que tu as pas le droit de faire ca "en utilisant bitkeeper".
-
[^]Re: Licence de BitKeeper
Posté par Philippe Fremy (page perso, ) le 13/04/2005 à 09:45. (lien). Évalué à 3.Justement, la licence de bitkeeper de Linus a ete revoquee. Donc, il n'a plus d'interdiction mais il ne peut plus utiliser bitkeeper gratuitement.
[+] Et subversion ??
Il existe pas mal de gestionnaires de sources disponibles
déjà testés à grande échelle ...
dommage de réécrire la roue franchement.
-
[^]Re: Et subversion ??
Posté par ouah (page perso, ) le 13/04/2005 à 08:10. (lien). Évalué à 1.Parce que Subversion n'est pas un source control distribué.
-
[^]Re: Et subversion ??
Posté par xeuzuex () le 13/04/2005 à 09:29. (lien). Évalué à 1.Ben justement ya un truc qui m'echappe :
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 () le 13/04/2005 à 09:48. (lien). Évalué à 7.en centralisé, tout le monde se connecte en même temps sur ton serveur,
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 () le 13/04/2005 à 09:53. (lien). Évalué à 1.>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.
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 () le 13/04/2005 à 10:03. (lien). Évalué à 2.Oui, mais prend mon cas personnel (qui n'est pas celui de tout le monde heureusement), je n'ai pas internet chez moi, donc quand je rentre chez et souhiate coder, je n'est pas besoin de faire les commits sur le serveur central.
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 () le 13/04/2005 à 10:12. (lien). Évalué à 1.Ok effectivement je suis d'accord avec toi c'est utile pour limiter les investissements matos et lorsque pour faire des commits qd tu n'as pas de connection Internet ou une ligne faible !
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 (page perso, ) le 13/04/2005 à 10:44. (lien). Évalué à 1.C'est obligatoire pour pouvoir faire en local certaines opérations qui étaient faites en réseau avec CVS. svn diff par exemple, ou svn status. Après, c'est vrai que pour les fichiers binaires, il pourrait ne conserver qu'un md5. T'as qu'à leur proposer :-)
-
-
[^]Re: Et subversion ??
Posté par Stéphane () le 13/04/2005 à 16:16. (lien). Évalué à 5.Pour mieux comprendre les différences entre SCM centralisé (CVS, Subversion..) et SCM décentralisé (Arch, BitKeeper..), une petite lecture (en anglais) s'impose (on y cause du cas Linux aussi):
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 tgl () le 13/04/2005 à 16:53. (lien). Évalué à 4.> Et subversion ??
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
Alors, comme d'hab sur linuxfr, on débat, on débat sans même se rendre compte qu'on est plus ou moins à côté de la plaque...
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
[...] son abandon simultané par de nombreux développeurs du noyau (dont Linus Torvalds bien sûr, mais aussi Greg Kroah-Hartman pour n'en citer qu'un) [...]Désolé je n'ai pas pu résister...
Ok, je connais le chemin ----> [ ]
Cette page a été générée par Templeet en 0.2501s (dont 0.0224 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.