Autre point important : quand tu envoies un patch, tu ne peux pas garder l'historique des merge. Le mainteneur ne peut pas savoir facilement si le patch a été intégré ou pas après coup.
Si tu envoies un deuxième patch qui est un surensemble du premier, et que le premier a déjà été appliqué, y'a conflit à coup sur.
La faiblesse de ce que tu propose, pour des petits projets, c'est le confort. Ne pas pouvoir commiter tant que tu n'as pas d'accès à l'archive, c'est casse gueule.
Maintenant, pour un projet plus important, tu as des tas de cas ou ton système ne marche pas _du tout_. Imagine que tu as une contribution qui n'est pas encore intégrée à la branche officielle (pas encore assez bien testée), mais que tu veuilles déjà développer une deuxième fonctionalité qui l'utilise. Sans gestionaire de versions décentralisé, t'es mal.
Autre exemple:
- Bonjour, voici ma contribution (cf. patch joint)
- J'y comprends rien à ton patch, coupe moi-ça en morceaux plus petits qu'on puisse s'y retrouver (réponse assez fréquente de Torvalds parait-il).
- Ben, euhhh
Encore un:
- Les gars, j'ai commencé à bosser sur la fonctionalité X, vous pouvez tester ma branche située ici: http://www.../(...)
- Pas mal. Moi, j'aurais bien mis Z à la place de T.
- OK, je fais ça. Voilà, c'est commité.
- Ah, ouais, c'est mieux. Tu peux changer U par V dans toto.c ?
- Je m'en occupe et je publie ça.
En un autre pour la forme:
- Voilà, j'ai fait pleins d'améliorations pour le logiciel XYZ. Ma branche est ici: http://toto.com/branche(...)
- Ah, tes patches 1, 12 et 42 m'ont l'air pas mal, je les intègre. Tes patches 33, 34 et 52 ont l'air pas mal, mais il y a X et Y qui ne vont pas. Les autres patches, j'en veux pas.
- OK, je viens de créer une branche ( http://toto.com/monautrebranche/(...) ), j'ai pris seulement les patches 33, 34 et 52, et j'ai corrigé les problèmes X et Y. Ça va maintenant ?
Mais, bon, tu peux argumenter que tu ferais tout ça avec un éditeur de texte et "cp -r". En effet, tu peux faire à la main ce que des outils te permettent de faire facilement de manière automatisée, y'a pas de scoop là.
> Pas facile de savoir où en est l'avancement des demandes de bug requests si
> chacun prend en charge 40 bugs dans son coin et commit sa branche une fois
> tous les 6 mois.
C'est clair. Je dis et je répète : un gestionnaire de version ne remplace pas une bonne organisation. Pour les bugs, je trouve qu'il est très important que la gestion des bugs soit centralisée. Idealement, le bugtracker doit garder trace de la personne responsable, de la branche dans laquelle c'est corrigé, et de la révision dans laquelle c'est intégré à la branche principale.
Pour la gestion des bugs, le meilleur exemple de ce qu'il ne faut pas faire, c'est l'historique du développement de GNU Arch ;-) (des bugs ont été rapportés dans 3 systèmes différents mais n'ont jamais été corrigés).
http://git.or.cz/(...) Two, interchangeable, on-disk formats are used:
* An efficient, packed format that saves space and network bandwidth.
* An unpacked format, optimized for fast writes and incremental work.
En fait, par défaut, il utilise la version "intégrale", et de temps en temps, on peut faire convertir explicitement dans l'autre format. Du coup, les dernières révisions (celles dont tu as vraiment besoin) sont accessibles rapidement, et les vieilles ne gaspillent pas l'espace disque, tout en restant accessibles.
Pour info, il y a des gens qui sont en train de migrer de GNU Arch à git, et qui en sont contents (cf. les recentes discussions sur gnu-arch-users).
Distante par rapport à toi. Quand je parle de gestion distribuée, c'est évidament entre deux repositories distants l'un de l'autres. Ma phrase est peut être pas 100% claire, mais tu aurais pu me laisser le bénéfice du doute avant de crier au scandale.
Par ailleurs, des branches, y'en a même en CVS, hein ...
> Ouais enfin à l'heure actuelle, là où tu n'as pas le net, y a pas mal de chance que tu n'ai pas l'électricité non plus !
1) Y'a encore des gens qui ont une connection pas permanente. C'est sympa de faire plusieurs commit et de publier le tout en une fois au moment ou tu te connecte.
2) Les pannes de réseau, ça arrive. Commiter en local, ça veut aussi dire être capable de commiter quand le serveur est planté.
3) Qu'évoquent pour toi les mots "ordinateur portable" par rapport à la connection au net ;-) ?
> Mais est-ce que ça marche à ce point si bien que ça pour gérer les conflits ?
Un gestionnaire de versions, quel qu'il soit, ne remplace pas une bonne organisation. Ca t'aide, c'est tout. Si deux personnes modifient le même bout de code, il y a conflit, point. Un intéret d'un gestionnaire de version par rapport au merge à la main, c'est qu'il te dit là ou sont les conflits, c'est déjà ça.
Avec un système centralisé, le conflit apparait au moment de l'update, avant le commit. Si l'update bousille ce que tu avais fait, c'est la galère (en général, tu as l'original des fichiers ou il y a conflit dans un coin, mais ça ne suffit pas forcément. Par exemple, tu peux avoir un update sans conflit mais qui ne compile même pas). Avec une branche par développeur, quand tu es content de toi, tu commit, et après, tu fais un merge. Si le merge casse tout, tu peux faire la différence entre ce qui vient de toi et ce qui vient du merge, c'est déjà ça.
En fait, la principale différence, c'est qu'en décentralisé, tu peux faire des branches distantes, donc, en particulier faire des branches chez toi sans demander l'avis de personne.
Ensuite, sur la gestion des branches, c'est une grosse faiblesse de SVN : Il ne garde pas l'historique des merge, donc, quand tu fais un merge, c'est a toi de dire quelle version utiliser comme ancetre commun.
Avec une gestion avancée des branches, tu dit "merge", et il se débrouille pour appliquer chaque patch une et une seule fois.
Il faut voir aussi que la gestion centralisée est aussi possible avec des outils comme Bazaar. Le décentralisé est en général un surensemble du centralisé.
J'ai joué un peu avec Darcs, c'est impressionnant de simplicité pour un débutant. Pour contribuer à un petit projet, j'ai lu un tutorial de 10 lignes, fait un get, des modifs en local, un "record" ou quelque chose comme ça, et "darcs send" a envoyé le tout par mail au mainteneur. Magique.
Bazaar-NG adopte aussi le système "répertoire de travail = repository". Il faut quand même faire attention à une chose : dans ce système, une création de branche se fait par copie intégrale du repository, qui est une opération chère. Je ne sais pas comment Darcs gère ça. Avec Bazaar-NG, on peut faire une copie avec liens en dur sur les systèmes qui le supportent, c'est une première optimisation. Des gens travaillent sur un stoquage centralisé qui permettra de faire une branche rapidement, et sans gaspiller d'espace disque.
Oui, tiens, j'ai oublié de citer svk (jamais essayé, donc moi non plus, je ne jugerai pas).
Pour la complexité de tla, Bazaar a quand même pas mal amélioré la situation. Pour un import par exemple, il n'y a plus que deux commandes (init-tree + import), et le message d'erreur si tu essaye de faire un import sans le init-tree, ou un commit à la place du import te dit quelle commande tu aurais du utiliser. Mais ça reste un gestionnaire de version assez complexe, c'est clair.
Bazaar-NG par contre est franchement simple à utiliser. Il y a un système de plugins qui permettra de garder les trucs compliqués à l'écard des débutants (je vois ça un peu comme les extensions firefox). Par ailleurs, les développeurs sont des gens très compétents, je leur fait confiance pour nous faire un système excellent.
Le plus gros à mon avis, c'est de pouvoir faire des commit réguliers qui ne dérangent pas les autres développeurs. Avec un gestionnaire de version centralisé et monobranche, on essaye en général de ne pas commiter si il y a eu regression. Avec Bazaar, ça m'arrive très souvent de commiter un truc que je sais être cassé, pour le réparer dans les commits suivants. Dans la branche principale, il n'y a pas de regression par contre.
Un autre intérêt, c'est de pouvoir travailler vraiment en local. Pour une machine connectée au net, ça veut dire de meilleures performances. Pour un portable qui n'est pas toujours connecté, ça veut dire pouvoir faire des choses infaisables autrement.
Un intérêt pratique est aussi pour la gestion des droits. Avec CVS/Subversion, un contributeur qui n'a pas les droits sur le repository est obligé d'envoyer ses contribution par patch. C'est la galère pour lui si il met du temps à mettre sa contribution au point et qu'il est obligé de faire des updates entre temps. Une solution est de lui donner les droits en commit sur le repository central, mais on n'aime pas donner les droits à n'importe qui non plus. Avec un gestionnaire de versions décentralisé, chacun a les droits sur son archive, et c'est tout. On peut travailler à plusieurs dans de bonnes conditions sans donner des droits à qui que ce soit (du moment que chacun a un bout d'espace web).
Pour aller plus loin, la gestion de version distribuée est un très bon moyen de favoriser la revue de code, et de garder une branche stable vraiment stable. C'est le point clé qui permet le développement de Linux comme on le connait depuis la version 2.6: Une nouvelle fonctionnalité est développée séparément, testée dans différentes branches, soumises à sa majestée Torvalds, qui en général t'enverra bouler « ton patch, il est pas bien, faut changer ça, ça, ça et ça ». Les demandes d'améliorations sont faites sur la branche dédiée à la fonctionalité en question, qui est maintenue un phase avec la branche principale. Un jour, le code est estimé comme étant de qualité suffisante et est intégré à la branche principale.
La gestion de version répartie, quand tu y as touché, tu as du mal à revenir à une gestion centralisée.
Mouais. Faut quand même relativiser sur la réduction de la consommation d'essence: Une F1 consomme quand même environ 60l aux 100, alors si ils trouvent une super techno qui leur fait gagner 10%, c'est cool pour eux, mais c'est quand même sur une autre échelle que les voitures particulières.
> Tu n'as qu'à t'informer un peu sur le système de freinage Porsche,
Non, il suffit de faire un peu de physique.
Quand tu es à 130 et que tu freines, ta vitesse diminue. Il y a un moment ou ta vitesse atteint 115, et puis elle continue à diminuer. Pendant le temps que ta voiture passe pour réduire ta vitesse de 130 à 115, ta voiture avance. La distance parcourue pendant ce temps est autant de distance de freinage à ajouter.
Enfin, je simplifie un peu. Mettons que tu aies une porsh super-extra-machin-bidule qui freine instantanément. Le truc qui passe de 130 à 0km/h en 0 secondes, donc, zero mêtres. Là, me diras-tu, « tu vois pas la différence ». Ben si. Parce qu'avant les 0 secondes qu'il te faut pour freiner, il faut que ton cerveau réagisse, que ton pied se déplace de l'accélérateur au frein. Ça prends environ 1 seconde pour un conducteur très réactif. À 130, tu as déjà fait 36 mètres en 1 seconde. À 110, tu as déjà fait 6 mètres de moins.
Donc, ta porsh super-extra-giga avec laquelle tu ne vois pas la différence, c'est une porsh qui recule de 6 mètres quand tu appuies sur le frein à 130 km/h.
> la voiture s'arrêtera de la même manière, moyennant un appuie un poil plus
> fort sur la pédale, et un léger plus de chaleur à évacuer dans le cas du 130.
L'argument qui tue !
« Si tu veux freiner plus vite, t'as qu'à appuyer plus fort sur la pédale ». Ben si c'est un freinage d'urgence, ça veut dire que tu es déjà au max, même si tu étais à 110 avant.
> Pour le reste, on est bien d'accord que la vitesse au moment du choc influe
> directement sur la gravité de l'accident. Mais de là à réduire la vitesse à 115
> au lieu de 130... Pourquoi ne pas la réduire à 0 ?
Ça s'appelle la gestion des risques. Tout autour de toi, tu as des trucs qui présentent un risque mortel, avec une probabilité faible. Quand la probabilité devient trop importante, en général, on élimine ou on interdit ce risque. Si la limitation a été fixée à 130, c'est sans doute que les gens qui ont pris cette décision ont estimé que c'était un bon compromis. Ça ne veut pas dire que le risque et la gravité d'un accident n'est pas à prendre en compte si on se pose la question de changer cette vitesse.
Oui, l'erreur ici est de croire que le rendement est constant, ce qui est faux avec une voiture a essence classique. (L'efficacité du moteur est de 0,30 (valeur très approximative) dans le calcul)
Le rendement dépends entre autres de la vitesse du moteur et du couple (donc du rapport de vitesse), du style de conduite, du fait que le moteur soit chaud ou pas... Au final, il est assez facile de calculer de façon théorique la dépense d'énergie, mais pour le rendement, difficile de faire autrement qu'en mesurant expérimentalement.
Aux petites vitesses, par exemple, il y a un effet trompeur qui est qu'en général, on n'a pas une vitesse constante à 50, alors qu'elle peut l'être à 120. Enfin, à moins de rouler à 120 en ville et à 50 sur autoroute ;-).
Si je te suis, les gens qui concoivent les F1 font de la recherche pour minimiser la consommation aux vitesses < 130kms/h ??
Ben non, la recherche sur les voitures de courses, c'est maximiser la vitesse en n'en ayant pas grand chose à foutre de la consommation. Ce sont deux problématique completement différentes. Si les technos testées sur les F1 étaient mises en pratique sur nos voitures, on aurait des monstres qui consommeraient 20l/100kms en ville.
Pour la tenue de route et le freinage, je veux bien croire qu'il y ai des retombées, mais tu es vraiment naif de croire que la recherche pour la F1 peut faire diminuer la consommation des voitures "normales".
Tu roules à une vitesse X sur l'autoroute. À un instant précis, il se passe un truc pas normal devant toi, je te laisse choisir le truc pas normal (mec qui s'endort au volant et qui rentre dans la voiture d'à coté, abruti qui teste l'efficacité de ses freins sur l'autoroute, camion qui se met en travers de la route, dinosaure qui traverse la route, ...).
a) tu freines
b) tu accélères
?
Si tu réponds a), je t'informe que ta survie dépends de ta distance de freinage.
Maintenant, tu peux nous trouver des dizaines de situations ou le risque d'accident ne dépends pas de la distance de freinage. Toujours est-il que
1) en cas de nécessité de freinage d'urgence, le risque d'accident est directement lié à la distance de freinage, donc à la vitesse.
2) en cas de collision, la gravité de l'accident est directement liée à la vitesse au moment de l'impact, donc à la vitess au moment ou tu as commencé à freiner.
Un pouillème de rien du tout en conséquence directe, mais ce qu'il faut compter, c'est aussi l'image que ça véhicule. Les « ouais, moi, je vais acheter une grosse voiture et rouler vite pour faire comme XXX à la télé ». Avoir une grosse voiture qui polue beaucoup (genre la super mode des 4x4 en ville) nous est présenté comme un idéal par les médias, et ça, ça a des conséquences pas négligeable.
> euh..... si les 25 mètres de distances supplémentaires te sont nécessaires
Fait le calcul : distance de freinage à 130, distance de freinage à 115, fait la soustraction. Tu tombera probablement légèrement au dessus de 25m (mon calcul me donne 35 metres, mais ça dépend de pleins d'autres facteurs).
> Bon, je vais faire court, parce que celle là elle est d'un débile profond.
Merci (en lisant mes commentaires, tu aurais remarqué que je fais 40kms aller-retour pour aller au boulot sans pour autant prendre ma voiture),
(plastique dans ta voiture, dans ton vélo, dans ton ordinateur, dans ta bouteille de lait, dans tes vêtements polaires, dans le flacon de ton gel douche, dérivés pétroliers dans tes produits de toilette, engrais dans la nourriture que tu manges, essence dans les véhicules pour produire la nourriture, dans les transports pour te l'apporter, etc.) est l'illustration parfaite du fait que nos politicards [...]
Et à aucun moment, tu ne t'es dit que ça n'était peut être pas seulement de la faute de nos connard de débiles mentaux d'abrutis de « policitard », mais que c'était un peu à toi de choisir ce que tu achètes ? Ça va bien de râler sur ce que font ou ne font pas les autres mais toi, tu fais quoi ?
> Que l'essence soit à 5 ¤ le litre ne me dérangerait pas s'il y avait vraiment la
> possibilité d'acquérir un véhicule fonctionnant sans essence
T'as pas les moyens d'acheter un vélo ?
Nan, sérieux, tu veux quoi comme véhicule personnel non polluant ? Tu préfères une voiture à air comprimé, avec une bonne grosse centrale à pétrole pour comprimer l'air, une voiture à pile à combustible qui tire son éléctricité des centrales nucléaires qui laissent des déchets qui seront encore là dans 25000 ans, ou une qui consomme de l'huile de colza cultivée aux pesticides et à l'engrais ?
L'alternative à la bagnole a essence, c'est pas j'attends qu'une solution miracle tombe. C'est je me bouge le cul, je fais les petits trajets en vélo, les trajets en ville en bus/tram/métro, je cherche quelqu'un avec qui co-voiturer pour les trajets réguliers, ...
... Et à la transporter correctement. Il y a environ 20% de l'electricité produite qui part en chaleur pendant le transport. (c'est toujours sympa de chauffer les pattes des oiseaux posés sur les fils, mais bon ;-).
[^] # Re: Bazaar
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. Évalué à 2.
Si tu envoies un deuxième patch qui est un surensemble du premier, et que le premier a déjà été appliqué, y'a conflit à coup sur.
[^] # Re: Bazaar
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. Évalué à 4.
Maintenant, pour un projet plus important, tu as des tas de cas ou ton système ne marche pas _du tout_. Imagine que tu as une contribution qui n'est pas encore intégrée à la branche officielle (pas encore assez bien testée), mais que tu veuilles déjà développer une deuxième fonctionalité qui l'utilise. Sans gestionaire de versions décentralisé, t'es mal.
Autre exemple:
- Bonjour, voici ma contribution (cf. patch joint)
- J'y comprends rien à ton patch, coupe moi-ça en morceaux plus petits qu'on puisse s'y retrouver (réponse assez fréquente de Torvalds parait-il).
- Ben, euhhh
Encore un:
- Les gars, j'ai commencé à bosser sur la fonctionalité X, vous pouvez tester ma branche située ici: http://www.../(...)
- Pas mal. Moi, j'aurais bien mis Z à la place de T.
- OK, je fais ça. Voilà, c'est commité.
- Ah, ouais, c'est mieux. Tu peux changer U par V dans toto.c ?
- Je m'en occupe et je publie ça.
En un autre pour la forme:
- Voilà, j'ai fait pleins d'améliorations pour le logiciel XYZ. Ma branche est ici: http://toto.com/branche(...)
- Ah, tes patches 1, 12 et 42 m'ont l'air pas mal, je les intègre. Tes patches 33, 34 et 52 ont l'air pas mal, mais il y a X et Y qui ne vont pas. Les autres patches, j'en veux pas.
- OK, je viens de créer une branche ( http://toto.com/monautrebranche/(...) ), j'ai pris seulement les patches 33, 34 et 52, et j'ai corrigé les problèmes X et Y. Ça va maintenant ?
Mais, bon, tu peux argumenter que tu ferais tout ça avec un éditeur de texte et "cp -r". En effet, tu peux faire à la main ce que des outils te permettent de faire facilement de manière automatisée, y'a pas de scoop là.
[^] # Re: Bazaar
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. Évalué à 4.
> chacun prend en charge 40 bugs dans son coin et commit sa branche une fois
> tous les 6 mois.
C'est clair. Je dis et je répète : un gestionnaire de version ne remplace pas une bonne organisation. Pour les bugs, je trouve qu'il est très important que la gestion des bugs soit centralisée. Idealement, le bugtracker doit garder trace de la personne responsable, de la branche dans laquelle c'est corrigé, et de la révision dans laquelle c'est intégré à la branche principale.
Pour la gestion des bugs, le meilleur exemple de ce qu'il ne faut pas faire, c'est l'historique du développement de GNU Arch ;-) (des bugs ont été rapportés dans 3 systèmes différents mais n'ont jamais été corrigés).
[^] # Re: Bazaar
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. Évalué à 4.
Ça n'est plus entièrement vrai :
http://git.or.cz/(...)
Two, interchangeable, on-disk formats are used:
* An efficient, packed format that saves space and network bandwidth.
* An unpacked format, optimized for fast writes and incremental work.
En fait, par défaut, il utilise la version "intégrale", et de temps en temps, on peut faire convertir explicitement dans l'autre format. Du coup, les dernières révisions (celles dont tu as vraiment besoin) sont accessibles rapidement, et les vieilles ne gaspillent pas l'espace disque, tout en restant accessibles.
Pour info, il y a des gens qui sont en train de migrer de GNU Arch à git, et qui en sont contents (cf. les recentes discussions sur gnu-arch-users).
[^] # Re: Après les journaux trollogène ...
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. Évalué à 0.
Par ailleurs, des branches, y'en a même en CVS, hein ...
[^] # Re: Après les journaux trollogène ...
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. Évalué à 1.
Bref, si tu lisait le texte que tu critiques ;-).
[^] # Re: Bazaar
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. Évalué à 4.
1) Y'a encore des gens qui ont une connection pas permanente. C'est sympa de faire plusieurs commit et de publier le tout en une fois au moment ou tu te connecte.
2) Les pannes de réseau, ça arrive. Commiter en local, ça veut aussi dire être capable de commiter quand le serveur est planté.
3) Qu'évoquent pour toi les mots "ordinateur portable" par rapport à la connection au net ;-) ?
> Mais est-ce que ça marche à ce point si bien que ça pour gérer les conflits ?
Un gestionnaire de versions, quel qu'il soit, ne remplace pas une bonne organisation. Ca t'aide, c'est tout. Si deux personnes modifient le même bout de code, il y a conflit, point. Un intéret d'un gestionnaire de version par rapport au merge à la main, c'est qu'il te dit là ou sont les conflits, c'est déjà ça.
Avec un système centralisé, le conflit apparait au moment de l'update, avant le commit. Si l'update bousille ce que tu avais fait, c'est la galère (en général, tu as l'original des fichiers ou il y a conflit dans un coin, mais ça ne suffit pas forcément. Par exemple, tu peux avoir un update sans conflit mais qui ne compile même pas). Avec une branche par développeur, quand tu es content de toi, tu commit, et après, tu fais un merge. Si le merge casse tout, tu peux faire la différence entre ce qui vient de toi et ce qui vient du merge, c'est déjà ça.
[^] # Re: Bazaar
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. Évalué à 3.
Ensuite, sur la gestion des branches, c'est une grosse faiblesse de SVN : Il ne garde pas l'historique des merge, donc, quand tu fais un merge, c'est a toi de dire quelle version utiliser comme ancetre commun.
Avec une gestion avancée des branches, tu dit "merge", et il se débrouille pour appliquer chaque patch une et une seule fois.
Il faut voir aussi que la gestion centralisée est aussi possible avec des outils comme Bazaar. Le décentralisé est en général un surensemble du centralisé.
[^] # Re: Tant qu'on y est...
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. Évalué à 2.
Bazaar-NG adopte aussi le système "répertoire de travail = repository". Il faut quand même faire attention à une chose : dans ce système, une création de branche se fait par copie intégrale du repository, qui est une opération chère. Je ne sais pas comment Darcs gère ça. Avec Bazaar-NG, on peut faire une copie avec liens en dur sur les systèmes qui le supportent, c'est une première optimisation. Des gens travaillent sur un stoquage centralisé qui permettra de faire une branche rapidement, et sans gaspiller d'espace disque.
[^] # Re: Arch est le premier, mais pas le seul
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. Évalué à 3.
Pour la complexité de tla, Bazaar a quand même pas mal amélioré la situation. Pour un import par exemple, il n'y a plus que deux commandes (init-tree + import), et le message d'erreur si tu essaye de faire un import sans le init-tree, ou un commit à la place du import te dit quelle commande tu aurais du utiliser. Mais ça reste un gestionnaire de version assez complexe, c'est clair.
Bazaar-NG par contre est franchement simple à utiliser. Il y a un système de plugins qui permettra de garder les trucs compliqués à l'écard des débutants (je vois ça un peu comme les extensions firefox). Par ailleurs, les développeurs sont des gens très compétents, je leur fait confiance pour nous faire un système excellent.
[^] # Re: Bazaar
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. Évalué à 10.
Le plus gros à mon avis, c'est de pouvoir faire des commit réguliers qui ne dérangent pas les autres développeurs. Avec un gestionnaire de version centralisé et monobranche, on essaye en général de ne pas commiter si il y a eu regression. Avec Bazaar, ça m'arrive très souvent de commiter un truc que je sais être cassé, pour le réparer dans les commits suivants. Dans la branche principale, il n'y a pas de regression par contre.
Un autre intérêt, c'est de pouvoir travailler vraiment en local. Pour une machine connectée au net, ça veut dire de meilleures performances. Pour un portable qui n'est pas toujours connecté, ça veut dire pouvoir faire des choses infaisables autrement.
Un intérêt pratique est aussi pour la gestion des droits. Avec CVS/Subversion, un contributeur qui n'a pas les droits sur le repository est obligé d'envoyer ses contribution par patch. C'est la galère pour lui si il met du temps à mettre sa contribution au point et qu'il est obligé de faire des updates entre temps. Une solution est de lui donner les droits en commit sur le repository central, mais on n'aime pas donner les droits à n'importe qui non plus. Avec un gestionnaire de versions décentralisé, chacun a les droits sur son archive, et c'est tout. On peut travailler à plusieurs dans de bonnes conditions sans donner des droits à qui que ce soit (du moment que chacun a un bout d'espace web).
Pour aller plus loin, la gestion de version distribuée est un très bon moyen de favoriser la revue de code, et de garder une branche stable vraiment stable. C'est le point clé qui permet le développement de Linux comme on le connait depuis la version 2.6: Une nouvelle fonctionnalité est développée séparément, testée dans différentes branches, soumises à sa majestée Torvalds, qui en général t'enverra bouler « ton patch, il est pas bien, faut changer ça, ça, ça et ça ». Les demandes d'améliorations sont faites sur la branche dédiée à la fonctionalité en question, qui est maintenue un phase avec la branche principale. Un jour, le code est estimé comme étant de qualité suffisante et est intégré à la branche principale.
La gestion de version répartie, quand tu y as touché, tu as du mal à revenir à une gestion centralisée.
[^] # Re: Qui est prêt à se passer de voiture?.
Posté par Matthieu Moy (site web personnel) . En réponse au journal à propos du prix de l'essence. Évalué à 2.
[^] # Re: Plus de consommation à 115 qu'à 130 ?
Posté par Matthieu Moy (site web personnel) . En réponse au journal à propos du prix de l'essence. Évalué à 3.
Non, il suffit de faire un peu de physique.
Quand tu es à 130 et que tu freines, ta vitesse diminue. Il y a un moment ou ta vitesse atteint 115, et puis elle continue à diminuer. Pendant le temps que ta voiture passe pour réduire ta vitesse de 130 à 115, ta voiture avance. La distance parcourue pendant ce temps est autant de distance de freinage à ajouter.
Enfin, je simplifie un peu. Mettons que tu aies une porsh super-extra-machin-bidule qui freine instantanément. Le truc qui passe de 130 à 0km/h en 0 secondes, donc, zero mêtres. Là, me diras-tu, « tu vois pas la différence ». Ben si. Parce qu'avant les 0 secondes qu'il te faut pour freiner, il faut que ton cerveau réagisse, que ton pied se déplace de l'accélérateur au frein. Ça prends environ 1 seconde pour un conducteur très réactif. À 130, tu as déjà fait 36 mètres en 1 seconde. À 110, tu as déjà fait 6 mètres de moins.
Donc, ta porsh super-extra-giga avec laquelle tu ne vois pas la différence, c'est une porsh qui recule de 6 mètres quand tu appuies sur le frein à 130 km/h.
> la voiture s'arrêtera de la même manière, moyennant un appuie un poil plus
> fort sur la pédale, et un léger plus de chaleur à évacuer dans le cas du 130.
L'argument qui tue !
« Si tu veux freiner plus vite, t'as qu'à appuyer plus fort sur la pédale ». Ben si c'est un freinage d'urgence, ça veut dire que tu es déjà au max, même si tu étais à 110 avant.
> Pour le reste, on est bien d'accord que la vitesse au moment du choc influe
> directement sur la gravité de l'accident. Mais de là à réduire la vitesse à 115
> au lieu de 130... Pourquoi ne pas la réduire à 0 ?
Ça s'appelle la gestion des risques. Tout autour de toi, tu as des trucs qui présentent un risque mortel, avec une probabilité faible. Quand la probabilité devient trop importante, en général, on élimine ou on interdit ce risque. Si la limitation a été fixée à 130, c'est sans doute que les gens qui ont pris cette décision ont estimé que c'était un bon compromis. Ça ne veut pas dire que le risque et la gravité d'un accident n'est pas à prendre en compte si on se pose la question de changer cette vitesse.
[^] # Re: effet de la boite de vitesse
Posté par Matthieu Moy (site web personnel) . En réponse au journal La vérité sur la consommation d'essence. Évalué à 4.
Le rendement dépends entre autres de la vitesse du moteur et du couple (donc du rapport de vitesse), du style de conduite, du fait que le moteur soit chaud ou pas... Au final, il est assez facile de calculer de façon théorique la dépense d'énergie, mais pour le rendement, difficile de faire autrement qu'en mesurant expérimentalement.
Aux petites vitesses, par exemple, il y a un effet trompeur qui est qu'en général, on n'a pas une vitesse constante à 50, alors qu'elle peut l'être à 120. Enfin, à moins de rouler à 120 en ville et à 50 sur autoroute ;-).
[^] # Re: Qui est prêt à se passer de voiture?.
Posté par Matthieu Moy (site web personnel) . En réponse au journal à propos du prix de l'essence. Évalué à 2.
Ben non, la recherche sur les voitures de courses, c'est maximiser la vitesse en n'en ayant pas grand chose à foutre de la consommation. Ce sont deux problématique completement différentes. Si les technos testées sur les F1 étaient mises en pratique sur nos voitures, on aurait des monstres qui consommeraient 20l/100kms en ville.
Pour la tenue de route et le freinage, je veux bien croire qu'il y ai des retombées, mais tu es vraiment naif de croire que la recherche pour la F1 peut faire diminuer la consommation des voitures "normales".
[^] # Re: Plus de consommation à 115 qu'à 130 ?
Posté par Matthieu Moy (site web personnel) . En réponse au journal à propos du prix de l'essence. Évalué à 2.
Tu roules à une vitesse X sur l'autoroute. À un instant précis, il se passe un truc pas normal devant toi, je te laisse choisir le truc pas normal (mec qui s'endort au volant et qui rentre dans la voiture d'à coté, abruti qui teste l'efficacité de ses freins sur l'autoroute, camion qui se met en travers de la route, dinosaure qui traverse la route, ...).
a) tu freines
b) tu accélères
?
Si tu réponds a), je t'informe que ta survie dépends de ta distance de freinage.
Maintenant, tu peux nous trouver des dizaines de situations ou le risque d'accident ne dépends pas de la distance de freinage. Toujours est-il que
1) en cas de nécessité de freinage d'urgence, le risque d'accident est directement lié à la distance de freinage, donc à la vitesse.
2) en cas de collision, la gravité de l'accident est directement liée à la vitesse au moment de l'impact, donc à la vitess au moment ou tu as commencé à freiner.
[^] # Re: Qui est prêt à se passer de voiture?.
Posté par Matthieu Moy (site web personnel) . En réponse au journal à propos du prix de l'essence. Évalué à 2.
[^] # Re: mouarf
Posté par Matthieu Moy (site web personnel) . En réponse au journal à propos du prix de l'essence. Évalué à 6.
Elle est morte de quoi, au fait, Marie Curie ?
[^] # Re: Tu t'es renseigné avant ?
Posté par Matthieu Moy (site web personnel) . En réponse au journal à propos du prix de l'essence. Évalué à 2.
Donc, c'est encore pire que ce que je disais !
[^] # Re: Plus de consommation à 115 qu'à 130 ?
Posté par Matthieu Moy (site web personnel) . En réponse au journal à propos du prix de l'essence. Évalué à 2.
distance (m) = (vitesse (en km/h)/10)^2
Pour doubler la distance de freinage, il suffit d'aller 1.4 fois plus vite.
[^] # Re: Plus de consommation à 115 qu'à 130 ?
Posté par Matthieu Moy (site web personnel) . En réponse au journal à propos du prix de l'essence. Évalué à 1.
Fait le calcul : distance de freinage à 130, distance de freinage à 115, fait la soustraction. Tu tombera probablement légèrement au dessus de 25m (mon calcul me donne 35 metres, mais ça dépend de pleins d'autres facteurs).
[^] # Re: Privatiser toutes les routes
Posté par Matthieu Moy (site web personnel) . En réponse au journal à propos du prix de l'essence. Évalué à 1.
Merci (en lisant mes commentaires, tu aurais remarqué que je fais 40kms aller-retour pour aller au boulot sans pour autant prendre ma voiture),
(plastique dans ta voiture, dans ton vélo, dans ton ordinateur, dans ta bouteille de lait, dans tes vêtements polaires, dans le flacon de ton gel douche, dérivés pétroliers dans tes produits de toilette, engrais dans la nourriture que tu manges, essence dans les véhicules pour produire la nourriture, dans les transports pour te l'apporter, etc.) est l'illustration parfaite du fait que nos politicards [...]
Et à aucun moment, tu ne t'es dit que ça n'était peut être pas seulement de la faute de nos connard de débiles mentaux d'abrutis de « policitard », mais que c'était un peu à toi de choisir ce que tu achètes ? Ça va bien de râler sur ce que font ou ne font pas les autres mais toi, tu fais quoi ?
[^] # Re: Privatiser toutes les routes
Posté par Matthieu Moy (site web personnel) . En réponse au journal à propos du prix de l'essence. Évalué à 5.
Euh, ça, t'inquiêtes, c'est déjà le cas. Sur la planête, je pense pas qu'il n'y ai plus de 20% de la population qui puisse se payer une voiture.
[^] # Re: Privatiser toutes les routes
Posté par Matthieu Moy (site web personnel) . En réponse au journal à propos du prix de l'essence. Évalué à 1.
> possibilité d'acquérir un véhicule fonctionnant sans essence
T'as pas les moyens d'acheter un vélo ?
Nan, sérieux, tu veux quoi comme véhicule personnel non polluant ? Tu préfères une voiture à air comprimé, avec une bonne grosse centrale à pétrole pour comprimer l'air, une voiture à pile à combustible qui tire son éléctricité des centrales nucléaires qui laissent des déchets qui seront encore là dans 25000 ans, ou une qui consomme de l'huile de colza cultivée aux pesticides et à l'engrais ?
L'alternative à la bagnole a essence, c'est pas j'attends qu'une solution miracle tombe. C'est je me bouge le cul, je fais les petits trajets en vélo, les trajets en ville en bus/tram/métro, je cherche quelqu'un avec qui co-voiturer pour les trajets réguliers, ...
[^] # Re: le pétrol est rare
Posté par Matthieu Moy (site web personnel) . En réponse au journal à propos du prix de l'essence. Évalué à 4.