El Titi a écrit 3948 commentaires

J'ignorais que le fait de couper les cheveux rendait stérile.
Impuissant, à la rigueur, comme pour Samson, mais stérile, je suis sur le c**

Il s'est marié avec le PS ?

Oui, ca permettrait de mieux cerner les mangeurs de SQUALE
http://linuxfr.org//2010/05/26/26896.html

Oui il manque un troncon comme indiqué ici
http://www.lgvsudeuropeatlantique.org/upload/Carte_RTE.jpg

En fait, tu as raison, désolé
http://www.lgvsudeuropeatlantique.org/pagesEditos.asp?IDPAGE(...)

Il me semblait qu'elle allait jusqu'à Bordeaux.

Voilà:

http://www.7sur7.be/7s7/fr/1505/Monde/article/detail/333224/(...)

Ils disposent même d'une rame spéciale, rien que pour eux.
Alors merci de ne pas sortir la phrase de son contexte.
L'ouverture de cette ligne était surtout motivée pour cette raison.
Maintenant je critique surtout la gabegie qui veut que l'on ait 2 parlements.
Hormis le cout en CO2 ceci coûte 200 milliojns par an.



Je préfère que l'argent public aille dans des grands travaux d'infrastructures qui rendent service à une grande part de la population, plutôt que dans des gadgets. Même si la rentabilité n'est peut être pas assurée, je pense que cette ligne rend service à un nombre important de personnes, ce qui correspond bien à un investissement "rentable" pour l'État à mon goût.

Chez moi le TGV Paris/Toulouse, on l'attend toujours.
En vertu de quels critères un toulousain serait moins important qu'un strasbourgeois ?
L'Etat et son arbitraire.

enveloppe qui vient d'ailleurs d'être augmentée:
http://www.lessentiel.lu/news/monde/story/17966170

Et puisque c'est le sujet à la mode en ce moment, un petit rappel sur la pénibilité du travail telle qu'elle s'applique à nos élus .. nationaux:
http://www.agoravox.fr/actualites/politique/article/reforme-(...)

Je comprend qu'il faille sauver le système par répartition.

Pas besoin, il suffit de se satisfaire de ça.
http://fr.narkive.com/2010/5/24/2252110-les-deputes-europeen(...)

ou encore de considérer qu'on a un parlement à Strasbourg et à Bruxelles juste pour satisfaire de égos nationaux


Qu'on a créé une ligne TGV non rentable juste pour que des députés parisiens puissent tranquillement se rendre à Strasbourg
...

Alors la faute à l'Europe ?
Ben non, je crois pas.
Par contre le démocratie représentative, on peut se poser la question.

Cela dépend de ton maître étalon
Tu pensais à celui-ci:
http://en.wikipedia.org/wiki/Sylvester_Stallone#Italian_Stal(...)

Remarquez, il vaut parfois mieux disposer d'un mètre étalon pour le casting.

mettre la main à la patte
Comme tu as péché par 2 fois, je serai bonne pâte et je te serre la pince patte au passage ;)

Bingo !!!

http://en.wikipedia.org/wiki/Buzzword_bingo

AMHA darcs, de par son architecture ne peut pas passer à l'échelle.
Le seul moyen de ne pas reconstruire une arbo à partir du premier patch est de stocker des révisions rattachées à des patchs particuliers.
Autant s'appuyer directement sur un système basé sur les révisions qui peut appliquer des optimisations (Delta inversé, ...)

Ensuite l'approche par clonage pose des problèmes puisque le fait de cloner n fois un repository distant ou des repositories clonés (cf. mon lien plus haut) surcharge le réseau pour rien. Il y a des possibilité d'optimiser avec un cache de chaque coté comme tu l'évoques mais ca ne règle pas le premier pb.


Après c'est sûr que si tu éludes la question des perfs, c'est plus facile.

Ça change que le logiciel tient compte du fait que deux patchs commutent*. Dans un tel cas, tu sais que les deux patchs appliqués dans n'importe quel ordre vont donner le résultat. Donc les deux patches sont indépendants, et tu peux annuler, transmettre, récupérer l'un sans l'autre.

(*Exemples de situations où deux patchs commutent: deux patchs qui ne modifient pas les mêmes lignes; un patch qui renomme "foo" en "bar" et un patch qui change des lignes dans "foo". En gros, deux patches qui ne "conflitent" pas commutent)

Oui mais même lorsqu'il n'y a pas de conflit, un système qui s'appuie sur des révisions gère/peut gérer aussi efficacement les changeset que les systèmes basés sur les patchs ala darcs ou Arch.
Avec la surcouche UCM de Clearcase par exemple tu as un système équivalent au merge: le deliver. tu peux choisir de reporter sélectivement un ou plusieur changeset et il y a une détection automatique si 1 changeset dépend de l'application d'un autre. Ca n'a rien à voir. A partir du moment moment où 2 révisions successives sont rattachées logiquement à un changement, c'est complètement équivalent à rattacher un diff à ce même.



Oui mais dans darcs les patchs sont des citoyens de première classe et les dépôts ne sont que des ensembles de patches. Pour l'analogie, je dirais que git/bazaar/mercurial sont autant prévus pour le cherry picking que SVN est prévu pour les branches.

Sauf que dans la pratique, reconstruire une révision de ton arborescence nécessite de recalculer tous les patchs en dépendance. Les performances s'en ressentent par rapport aux autres pour un avantage conceptuel à restant à démontrer.


OK, j'ai pas encore eu l'occasion de travailler vraiment avec Mercurial, si ça fait ça c'est intéressant. Mais donc au passage on doit apprendre deux concepts de branches.

Tu n'es pas obligé de les connaitre les 2 ni de les utiliser: le projet Mercurial en lui-même a choisi la même approche que toi pour son propre hébergement. Mais comme déjà indiqué chaque technique a ses propres avantages et inconvénients.
Je trouve rassurant de pouvoir changer d'approches lorsqu'on en a besoin.
Réfère toi à ce blog si tu veux plus d'infos pour comprendre les différences entre chaque approche.
http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me(...)



Y'a 2 réponses possibles à la première partie de ta phrase : "non" parce qu'il n'y a pas de branches dans darcs, mais seulement des dépôts. Càd, un dépôt = un répertoire = une branche. Mais je pourrais répondre quad même "oui" en te disant que tu n'as qu'à nommer chaque répertoire avec le nom qui va bien et ça te fait une branche nommée. Chez moi les branches sont placées dans des répertoires frères.

cf. mon lien: problèmes de perfs, pbs d'intégration dans les IDE.

Bon comme ce cher Zenitram à l'air de tarder à réagir, je vais modestement reprendre son flambeau.

Le plus dur sera de convaincre les industriels qui optimisent la lecture du H.264 au niveau du hardware.

Ca c'est fait !

Merci pour ta tentative d'explication bien argumentée, mais j'avoue que j'ai toujours du mal à comprendre.


Si tu prends subversion, le graphe qui est considéré c'est un graphe où les sommets sont des révisions et les arcs veulent dire "est la révision suivante de", et le graphe ne peut former qu'une ligne.

C"est encore plus simpliste que ça. Il s'agit d'une bête séquence linéaire de révision complète. Les branches et tag son simplement des recopies de sous-arborescence. Il n'y a pas de graphes (DAG) à proprement parler.


Pour darcs, le graphe qui est considéré a pour sommets des patchs, et les arcs signifient "dépend de". Par exemple, si un patch A qui modifie des lignes qui ont été au préalable modifiées par un patch B, alors A dépend de B. Et on a une partie du graphe qui est : A -> B. Donc par exemple si A répare un bug, tu sais
que pour obtenir A tu dois obtenir B si tu ne l'as pas déjà.

Oui c'est l'histoire des piquets et des barrières mais je ne vois pas ce que ca change.



Autant dire que pour un même projet avec des mêmes "commits", le graphe de darcs a, en général, moins d'arcs que le graphe de git par exemple.


Je ne vois pas en quoi ca évite de créer des patchs/revisions pour résoudre le conflit. Si tu as A->B et A->C et que tu veux réconcilier les modifs concurrentes de C avec B, tu dois, soit créer une revision C qui gère tes conflits, soit appliquer le patch C dans ton workspace et commiter un patch D après résolution. Avec git&Co, on a A->B, A->C, B->D et C->D
Avec des patch ala darcs on a A->B, A->C, et B->D c'est ça ?
Pourtant c'est utile de conserver ce lien C->D pour éviter de réappliquer ce patch lors d'un futur merge éventuel entre ces 2 branches. C'est ce qu'on appelle la mémoire de merge.



Premier intérêt, ça permet de facilement récupérer un patch d'une branche à l'autre. Tu as ta branche de développement de ton projet et tu as la branche de ta release en préparation. Si dans la branche de développement quelqu'un a mis un patch intéressant (qui résout un bug, etc.) que tu veux faire passer dans la branche release, c'est juste une histoire de faire un pull. (On appelle ça le "cherry-picking"). Si c'est un patch qui dépend de rien d'instable, ça se passe bien.

Le cherry picking , ce n'est pas propre à darcs. Tous les DVCS le gèrent et même SVN le fait (mal car pas de merge cylciques).

Ensuite après ton pull, tu te retrouves quand même avec plusieurs heads (la tienne et la sienne) et il faut bien faire un resolve pour arbitrer les conflits.
Mercurial/Monotone fonctionnent comme ça de base aussi. quand à Git mis à part qu'une branche ne peut avoir qu'une head et qu'il faut les nommer ou qu'elles suivent des conventions (remote) il n'y a rien de plus à faire. Un conflit est un conflit et il faut le résoudre, non ?


Deuxième intérêt, ça permet de faire des branches et des fusions sans s'en rendre compte et surtout, sans avoir besoin d'apprendre les concepts de branches et de fusions. Tu peux voir chaque dépôt darcs comme une branche et chaque pull ou push comme une fusion. Ça se voit dans l'interface de darcs, y'a pas de commande à la "git checkout" ou "git branch". De même dans l'historique, tant que tu n'as pas de

C'est le cas avec Mercurial aussi. Tu peux choisir de nommer des branches ou de travailler avec des clones.
Chaque approche a ses avantages et ses inconvénients, on en a déjà un peu parlé ici.
http://linuxfr.org//comments/1125043,1.html
J'espère que Darcs propose aussi les branches nommées parce que pour des projets conséquents ce manque me parait rédhibitoire



De plus, quand j'avais testé mercurial et bazaar, la fusion de deux branches nécessitait de taper des commandes supplémentaires même quand les modifications étaient indépendantes.
En gros le fait que le pull du repository et l'update de ton répertoire local soient 2 opérations différentes te gène.
Ca ne ma parait être un critère de décision primordial.
Aux dernières nouvelles, les perfs de darcs étaient bien en deçà de ses concurrents. Ca a changé depuis ?

C'est, vrai le droit moral de l'auteur.

Je l'ignorais mais je cite au moins la source de mon plagiat:
http://www.funfou.com/blagues/hiver.phtml

C'est l'histoire d'un bûcheron qui coupe du bois pour l'hiver. Un Indien passe par là et le bûcheron lui demande : " L'hiver sera-t-il froid, grand chef indien? "

"Oui, HUGH! hiver très froid."

Alors le bûcheron se remet à couper du bois de plus belle. Le lendemain, l'Indien repasse par là et le bûcheron lui demande si l'hiver sera vraiment aussi froid qu'on le dit. L'indien répond: "Oui, HUGH! Hiver très rigoureux..."

Alors le bûcheron reprend sa scie et coupe une montagne de bois. Le jour suivant, l'Indien repasse en disant : "Hiver très, très rigoureux."

Le bûcheron intrigué, lui demande: "Mais enfin, dis-moi comment tu devines que l'hiver sera très froid."

Il lui répond: "Chez nous, on a un dicton : Quand l'homme blanc coupe du bois, c'est que l'hiver va être froid!"

Linux/Ubuntu, tu veux dire ? Personnellement, j'avoue qu'ils me gonflent un peu ces suppôts de Torvalds, à vouloir accoler ce sigle alors que Linux ne représente qu'une partie insignifiante d'Ubuntu.

Avec ca, on n'est pas dans la merde !

J'ai eu beau relire le wiki, visionner la vidéo, je n'ai pas compris la différence avec les autres DVCS.

Darcs réorganise automatiquement le graphe des commits en fonction des diffs, c'est ça ?
Quel est l'intérêt ?

entre si ont retire les trucs qui viennent de Chine,

http://www.20minutes.fr/article/397632/A-la-Une-L-iPad-pouss(...)

La démonstration que j'attends est celle qui montrerait que la reconnaissance de la PI, du monopole sur les idées et de tout l'arbitraire qui l'entoure serait économiquement plus profitable qu'une libre concurrence qui ne la reconnait pas.

Le rôle de l'Etat m'importe peu.
Une idée provoque certes des externalités positives, mais en lui appliquer un monopole d'exclusivité, j'en doute.

Bref "l'effet positif pour TOUS les tiers" reste à démontrer.

C'est évident qu'il pouvait le payer, par ex en empruntant, en vendant sa maison, résiliant son abonnement internet, etc...

Ah bon, j'aurais plutôt dit que c'est évident qu'il voulait pas le payer au prix où il est, voire ne pas le payer du tout. Mais tu es mieux placé pour savoir la vérité, tu es tellement intelligent.

Qu'il ne consomme pas ce qu'il ne paye pas, pas de pb, un contrat est un contrat. Mais de là en déduire qu'indubitablement, il sacrifierait le reste pour se le payer plutôt que de ne pas l'acheter. Qu'en plus ca serve de base à des calculs savants pour estimer un manque à gagner, chapeau.

Ta logique nous est vraiment supérieure, je m'incline.

Vivement qu'on invente les précogs
http://fr.wikipedia.org/wiki/Minority_Report