1. #1
    Rédacteur

    Avatar de Yogui
    Homme Profil pro
    Directeur technique
    Inscrit en
    février 2004
    Messages
    13 724
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yonne (Bourgogne)

    Informations professionnelles :
    Activité : Directeur technique

    Informations forums :
    Inscription : février 2004
    Messages : 13 724
    Points : 29 845
    Points
    29 845

    Par défaut Le projet PHP passe de CVS à Subversion, auriez-vous choisi le même gestionnaire de versions ?

    Salut à tous,

    Je me permets ce message d'information pour les amateurs de Subversion.

    Le projet PHP va bientôt passer de CVS à Subversion. La nouvelle architecture est prête, les scripts de migration sont prêts :
    http://marc.info/?l=php-internals&m=124567675723251&w=2

    Le script de migration nécessite environ 18 heures pour traiter toute la base de commits CVS. L'idée est de passer la date de sortie de PHP 5.3.0, qui est l'une des plus grosses versions jusqu'à présent, et d'opérer la migration juste après cette date.

    D'autres VCS ont été envisagés par le groupe, mais aucun ne semblait avoir la maturité de Subversion. C'est là que j'aimerais avoir votre avis : que pensez-vous de cette décision ? Quels VCS aujourd'hui permettent d'accueillir des projets de la taille de PHP, avec des développeurs issus d'horizons totalement différents ? Si vous pouviez répondre sans troller svp

  2. #2
    Membre confirmé Avatar de Grabeuh
    Homme Profil pro
    Développeur Web
    Inscrit en
    février 2009
    Messages
    114
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2009
    Messages : 114
    Points : 635
    Points
    635

    Par défaut

    Git est quand même le VCS du noyau Linux, ce qu'on peut considérer comme un gage de fiabilité et de support pour des projets massifs, en plus, sa gestion des branches est une pure merveille.
    Et je pense que sa quantité d'utilisateurs, encore marginale, et sa complexité de mise en oeuvre et surtout d'utilisation ont du rebuter les core developpers de PHP.


    J'estime par contre que Mercurial est à l'heure actuelle un concurrent sérieux à Subversion pour le contrôle de versions sur des projets de la taille de PHP. Pratiquement aussi mûr, sa gestion des branches est néanmoins beaucoup plus fine et subtile et surtout beaucoup moins lourde à gérer : les merges sont beaucoup plus aisés et ne nécessitent pas une copie complète de la branche comme c'est le cas pour SVN.
    En plus, il est, comme git, décentralisé et par là même beaucoup plus résistant aux pannes.

    Après, je ne conteste pas le choix de SVN : c'est l'un des plus répendus et des plus éprouvés avec CVS.

  3. #3
    Candidat au Club
    Profil pro
    Inscrit en
    juin 2009
    Messages
    3
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2009
    Messages : 3
    Points : 4
    Points
    4

    Par défaut

    Pour l'avoir testé, pour sa simplicité d'installation et d'utilisation, pour sa portabilité, pour sa capacité a être utilisable hors ligne, mercurial est vraiment le meilleur VCS.

    Mais c'est comme tout, bien qu'il y ai meilleur ailleurs on a du mal a changer ses habitudes.

  4. #4
    Membre éclairé
    Avatar de mamelouk
    Profil pro
    Inscrit en
    mai 2005
    Messages
    867
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : mai 2005
    Messages : 867
    Points : 810
    Points
    810

    Débugger du code est deux fois plus dur que d'en écrire.
    Donc, si vous écrivez votre code aussi intelligemment que vous le pouvez, vous n'etes, par définition, pas assez intelligent pour le débugger.

  5. #5
    Membre confirmé Avatar de Grabeuh
    Homme Profil pro
    Développeur Web
    Inscrit en
    février 2009
    Messages
    114
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2009
    Messages : 114
    Points : 635
    Points
    635

    Par défaut

    Le soucis de Bazaar est sa TRES grande lenteur par rapport à Mercurial. Pour la plupart des opérations, il met pratiquement 2 fois plus de temps, et pour les plus lourdes il en met 10 fois plus.

    Petit comparatif des temps mis pour effectuer des opérations entre Bazaar et Mercurial (pour les gens peu doués en physique, hg est le symbole atomique du mercure): (le comparatif date de 2006, ça a peut-être changé depuis, si vous en avez des plus récents, je suis prenneur)

    repository initialization: hg 2.8x faster
    hg: 0.67 seconds
    bzr: 1.93 seconds

    adding files for committal: hg 2.4x faster
    hg: 1.12 seconds
    bzr shared repository: 2.73 seconds

    committing new files: hg 3x faster
    hg: 4.08 seconds
    bzr: 12.36 seconds

    commit an append line to every file: hg 2.3x faster
    hg: 8.63 seconds
    bzr: 20.1 seconds

    clone a repository: hg 4x faster
    hg: 3.23 seconds
    bzr shared repository: 12.92 seconds

    committing in the cloned branch: hg 2x faster
    hg: 10.6 seconds
    bzr shared repository: 21.79 seconds

    Initialize remote repository: hg 2.8x faster
    hg: 5.71 seconds
    bzr: 16.43 seconds

    Push local repository to remote repository: hg 7.1x faster
    hg: 11.38 seconds
    bzr shared repository: 80.99 seconds

    Branch from remote repository: hg 1.9x faster
    hg: 8.16 seconds
    bzr shared repository: 15.62 seconds (vanilla was 52.85 seconds)

    Push appended line change to server: hg 10.1x faster
    hg: 5.36 seconds
    bzr: 54.62 seconds

    Pull appended line change from server: hg 1.8x faster
    hg: 9.65 seconds
    bzr shared repository: 17.69 seconds (46.89 seconds for vanilla bzr)

    source

  6. #6
    Membre éclairé
    Avatar de mamelouk
    Profil pro
    Inscrit en
    mai 2005
    Messages
    867
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : mai 2005
    Messages : 867
    Points : 810
    Points
    810

    Par défaut

    bof... 2 à 4 fois plus lent pour des opérations en dessous de la seconde ca ne m'impressonne pas plus que ca.. surtout que les benchmarks datent de plus de 3 ans. les deux outils sortaient a peine de beta..

    bazaar a pour lui launchpad. je crois pas qu'il existe d'equivalent pour hg.

    enfin comme l'explique l'article que tu as donné, les outils sont similaire, ca ne me dérangerai pas de passer de l'un à l'autre

    Débugger du code est deux fois plus dur que d'en écrire.
    Donc, si vous écrivez votre code aussi intelligemment que vous le pouvez, vous n'etes, par définition, pas assez intelligent pour le débugger.

  7. #7
    Membre confirmé Avatar de Grabeuh
    Homme Profil pro
    Développeur Web
    Inscrit en
    février 2009
    Messages
    114
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2009
    Messages : 114
    Points : 635
    Points
    635

    Par défaut

    Alors oui, ça date, mais de nos jours encore, Bazaar a la réputation d'être plus lent que Mercurial (que ce soit avéré ou juste une rumeur galopant depuis l'époque des benchmarks que j'ai proposé).
    J'ai eu vent de projets lancés cette année qui bien que préférant les possibilités offertes par bzr se sont tournés vers hg car repoussés par sa lenteur.
    Cependant Bazaar a aussi des avantages que je ne renie pas : ça me fait une pause café pendant qu'il mouline (méchant le troll, méchant).

    Après, c'est selon les gouts de chacun, je respecte parfaitement ton choix mais dans "mon cas intimement personnel" je lui préfère Mercurial pour sa réactivité.

    (PS : si quelqu'un trouve des benchmarks plus récents, qu'il me les fasse parvenir, ça m'interesse beaucoup de voir l'évolution, et le cas échéant de voir que je me trompe)

  8. #8
    Membre chevronné
    Profil pro
    Inscrit en
    janvier 2007
    Messages
    1 448
    Détails du profil
    Informations personnelles :
    Âge : 33
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : janvier 2007
    Messages : 1 448
    Points : 2 074
    Points
    2 074

    Par défaut

    Bonjou,

    J'ai débuté avec subversion, parce que je n'avais pas le temps m'atteler à des test, car il à une réputation (bonne ou pas je vous laisse juge).

    Cependant, étant encore novice dans le scm, je dois bien dire que la première fois que j'ai mergé mon projetr svn,
    - 1 je me suis fait des frayeurs
    2 - Mais qu'eeeeeeeeeessssttttt ce que c'était long... Surtout que j'avais pas le temps....

    En faits, vous cité git, mercurial et bazaar ces outils vous apporte t'il un plus par rapport à cvs ou svn ? Je n'arrive pas bien à cerner leur domaines de compétences.

    merci,
    aplus

  9. #9
    Membre confirmé Avatar de Grabeuh
    Homme Profil pro
    Développeur Web
    Inscrit en
    février 2009
    Messages
    114
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2009
    Messages : 114
    Points : 635
    Points
    635

    Par défaut

    Les outils dont nous parlons sont des VCS décentralisés, permettant de travailler en hors ligne, de disposer de son "mini" repository en local puis de synchroniser avec un dépot distant.

    Ils offrent tous des possibilités de branches plus évoluées que Subversion (travailler sur une branche est déjà complexe avec subversion, sur git tu peux en avoir 5 ou 6 simultanées sans aucun soucis, idem pour les deux autres dans une moindre mesure). Les merges sont aussi plus optimisées, moins longs et mieux pensés qu'avec SVN.

    Etant dscentralisés, si le dépot principal tombe, tu peux avoir autant de dépot secondaire que tu veux avec ces trois outils, ce que SVN ne permet pas ou difficilement. La tolérance aux pannes en est grandement augmentée.

    Ce sont les 3 points forts qui me passent actuellement par la tête, il doit y en avoir d'autres mais ils ne me viennent pas à l'esprit.

  10. #10
    Membre habitué

    Inscrit en
    février 2004
    Messages
    342
    Détails du profil
    Informations forums :
    Inscription : février 2004
    Messages : 342
    Points : 193
    Points
    193

    Par défaut

    me passer de cvs pour autre chose ?

    => à ça oui je l'aurais fait, et depuis un bail


    maintenant svn ou un autre...

    je suis utilisateur de svn depuis plusieurs années. Je l'aime bien, mais il a aussi ses défauts.

    j'entends pas mal parler de mercurial à droite à gauche, mais jms testé perso. y'a de ca qq temps, j'avais d'excellents echos de perforce, mais bon à l'époque il était cher le coquin

    bref, mon 50 cent : oui j'aurais switché csv pour svn, trois fois oui

  11. #11
    Membre chevronné
    Profil pro
    Inscrit en
    janvier 2007
    Messages
    1 448
    Détails du profil
    Informations personnelles :
    Âge : 33
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : janvier 2007
    Messages : 1 448
    Points : 2 074
    Points
    2 074

    Par défaut

    Citation Envoyé par Grabeuh Voir le message
    Les outils dont nous parlons sont des VCS décentralisés, permettant de travailler en hors ligne, de disposer de son "mini" repository en local puis de synchroniser avec un dépot distant.

    Ils offrent tous des possibilités de branches plus évoluées que Subversion (travailler sur une branche est déjà complexe avec subversion, sur git tu peux en avoir 5 ou 6 simultanées sans aucun soucis, idem pour les deux autres dans une moindre mesure). Les merges sont aussi plus optimisées, moins longs et mieux pensés qu'avec SVN.

    Etant dscentralisés, si le dépot principal tombe, tu peux avoir autant de dépot secondaire que tu veux avec ces trois outils, ce que SVN ne permet pas ou difficilement. La tolérance aux pannes en est grandement augmentée.

    Ce sont les 3 points forts qui me passent actuellement par la tête, il doit y en avoir d'autres mais ils ne me viennent pas à l'esprit.
    MH Effectivement !
    Je comprend mieux vos choix, et ils rapportent tout à fait à mes craintes et frayeurs d'utilisateurs et (pseudo) administrateurs du dépôt.

    J'ai plus qu'à ! Merci : )

    a plus

  12. #12
    Rédacteur

    Avatar de Yogui
    Homme Profil pro
    Directeur technique
    Inscrit en
    février 2004
    Messages
    13 724
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yonne (Bourgogne)

    Informations professionnelles :
    Activité : Directeur technique

    Informations forums :
    Inscription : février 2004
    Messages : 13 724
    Points : 29 845
    Points
    29 845

    Par défaut

    Citation Envoyé par Grabeuh Voir le message
    Etant dscentralisés, si le dépot principal tombe, tu peux avoir autant de dépot secondaire que tu veux avec ces trois outils, ce que SVN ne permet pas ou difficilement. La tolérance aux pannes en est grandement augmentée.
    À mon humble avis, c'est un problème mal posé. Il existe des solutions techniques pour faire du mirroring de machines à base de l'adresse IP, je crois que cela s'appelle "IP failover" ou quelque chose comme cela. Par exemple sous OpenBSD, on peut mettre 2 machines ayant la même adrese IP sur le même réseau, l'une étant une réplication de l'autre : si la 1° tombe, la 2° prend automatiquement le relai puisqu'elle a la même IP.

    Ce genre d'architecture me semble plus facile à gérer qu'un système décentralisé, dans la mesure où on sait toujours où est la bonne version du code source.

  13. #13
    Membre chevronné
    Profil pro
    Inscrit en
    janvier 2007
    Messages
    1 448
    Détails du profil
    Informations personnelles :
    Âge : 33
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : janvier 2007
    Messages : 1 448
    Points : 2 074
    Points
    2 074

    Par défaut

    Citation Envoyé par Yogui Voir le message
    À mon humble avis, c'est un problème mal posé. Il existe des solutions techniques pour faire du mirroring de machines à base de l'adresse IP, je crois que cela s'appelle "IP failover" ou quelque chose comme cela. Par exemple sous OpenBSD, on peut mettre 2 machines ayant la même adrese IP sur le même réseau, l'une étant une réplication de l'autre : si la 1° tombe, la 2° prend automatiquement le relai puisqu'elle a la même IP.

    Ce genre d'architecture me semble plus facile à gérer qu'un système décentralisé, dans la mesure où on sait toujours où est la bonne version du code source.
    oui mais ta solution nécessite plus de moyens financiers (bon je sais, c'est pas le bout du monde deux serveurs à 50 euros).
    Alors que si c'est décentralisé, effectivement, l'aspect redondant semble mieux gérés par les choix d'archi.
    Reste à savoir si après il existe les outils nécessaire pour merger les versions distribuées et en faire naître un projet commun (cas où le serveur centrale tombe et qu'il ne reste plus que des versions clientes).

    Par contre, le fail over, si cela te permet effectivement de ré attribuer dynamiquement une ip à une seconde machine.
    Il me semble que ce procédé ne serait pas très adapté à ce process car comme c'est de la gestion de version, il faudrait, pour être iso, faire une copie instantanée des modifications sur le slave (un peu comme du mysql replication).
    Ainsi seulement tu pourrais de permettre de faire jouer fail over sans que toi ni tes users ne se pose la question de la qualité du dépôt sur l'esclave.

    A cause de cela, sur un svn, il est peut être plus intéressant de monter une bécane moloss sur du raid car cette technique me semble proposer une bien meilleure tolérance à la panne des dd.

    D'ailleurs vous connaissez des gros dépot ? Ils ont des gros besoins de scaling (en nombre de clients) sur ces outils ?


    fin voilà.

    a plus

  14. #14
    Rédacteur

    Avatar de Yogui
    Homme Profil pro
    Directeur technique
    Inscrit en
    février 2004
    Messages
    13 724
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yonne (Bourgogne)

    Informations professionnelles :
    Activité : Directeur technique

    Informations forums :
    Inscription : février 2004
    Messages : 13 724
    Points : 29 845
    Points
    29 845

    Par défaut

    Justement, la technique dont je parlais permet d'avoir une machine "copie permanente" avec la même IP, elle prend donc le relai dès que la 1° tombe. D'après ce que j'en ai compris, c'est l'OS qui s'occupe de toute la réplication et du réveil de la 2° machine en cas de panne de la 1° (je crois que c'est une question de pings fréquents de l'une à l'autre).

    Le RAID est un autre système, c'est de la réplication au niveau du disque et non de la machine complète. Ce n'est pas incompatible, au contraire c'est en plus

    Je crois qu'il est préférable d'avoir de la redondance matérielle (alimentation, disques, machines etc.) plutôt que de la réplication logicielle. C'est un plus coûteux à court terme mais on ne se pose jamais la question "où est la bonne version de mon code ?", donc sur le long terme je ne suis pas sûr que ce soit vraiment plus onéreux.

  15. #15
    Rédacteur

    Avatar de Yogui
    Homme Profil pro
    Directeur technique
    Inscrit en
    février 2004
    Messages
    13 724
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yonne (Bourgogne)

    Informations professionnelles :
    Activité : Directeur technique

    Informations forums :
    Inscription : février 2004
    Messages : 13 724
    Points : 29 845
    Points
    29 845

    Par défaut

    Salut

    Pour information, la migration est terminée :
    http://cvs.php.net/viewvc.cgi/
    http://svn.php.net/viewvc/

    Avec au passage une réorganisation des répertoires, il était temps

  16. #16
    Membre confirmé Avatar de Grabeuh
    Homme Profil pro
    Développeur Web
    Inscrit en
    février 2009
    Messages
    114
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2009
    Messages : 114
    Points : 635
    Points
    635

    Par défaut

    Citation Envoyé par Yogui
    À mon humble avis, c'est un problème mal posé. Il existe des solutions techniques pour faire du mirroring de machines à base de l'adresse IP, je crois que cela s'appelle "IP failover" ou quelque chose comme cela. Par exemple sous OpenBSD, on peut mettre 2 machines ayant la même adrese IP sur le même réseau, l'une étant une réplication de l'autre : si la 1° tombe, la 2° prend automatiquement le relai puisqu'elle a la même IP.

    Ce genre d'architecture me semble plus facile à gérer qu'un système décentralisé, dans la mesure où on sait toujours où est la bonne version du code source.
    C'est un exemple parmis tant d'autres de l'interet d'un système décentralisé, qui n'est pas non plus exempt de défauts. Et ce n'est pas son atout principal par rapport aux autres produits de versionning. Comme je l'ai dit, Hg, git et Bzr sont plus adaptés pour des projets qui vont nécessiter des développements parallèles de plusieurs branches, qui sont nettement plus simples à manier qu'avec SVN. Et c'est là leur principale force.
    Le fait de pouvoir travailler en local sans avoir à dupliquer et synchroniser des repositories locaux et distants est aussi une différence fondamentale.

    Cette tolérance aux pannes n'est pas une fonctionnalité désirée dès le départ, c'est une conséquence, certes bien pratique, du modèle décentralisé utilisé.
    Et quitte à choisir un outil, autant en prendre un qui nous simplifie la vie au maximum sur des opérations lourdes, et qui en bonus nous évite de devoir déployer une solution de réplication en temps réel sur des serveurs.

    Après, le choix d'un outil de versionning, c'est comme les gouts, les couleurs ou les OS : ça ne se discute pas.

  17. #17
    Candidat au Club
    Profil pro
    Inscrit en
    juin 2009
    Messages
    3
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2009
    Messages : 3
    Points : 4
    Points
    4

    Par défaut

    Rien n'empeche de faire de l'ip failover sur un serveur avec mercurial.

    Les SCM decentralisé ont toutes les fonctionnalité de SVN et plus.

    On retrouve un excelent article sur linux magazine (http://www.ed-diamond.com/feuille_lmag118/index.html) page 42

  18. #18
    Membre chevronné
    Profil pro
    Inscrit en
    janvier 2007
    Messages
    1 448
    Détails du profil
    Informations personnelles :
    Âge : 33
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : janvier 2007
    Messages : 1 448
    Points : 2 074
    Points
    2 074

    Par défaut

    Citation Envoyé par Yogui Voir le message
    Salut

    Pour information, la migration est terminée :
    http://cvs.php.net/viewvc.cgi/
    http://svn.php.net/viewvc/

    Avec au passage une réorganisation des répertoires, il était temps
    En tout cas elle est pratique leur interface de navigation. Particulièrement ce select for diff.
    D'ailleurs, quels sont vos interfaces web/local pour naviguer et tirer parti du dépot ? Je pense à smartsvn, ou websvn.

    Git et mercurial utilise des outils complètement différent ?

  19. #19
    Membre confirmé Avatar de Grabeuh
    Homme Profil pro
    Développeur Web
    Inscrit en
    février 2009
    Messages
    114
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2009
    Messages : 114
    Points : 635
    Points
    635

    Par défaut

    Il me semble que des projets utilisant Redmine comme outil de gestion de projet peuvent disposer d'interfaces web pour SVN, Mercurial, Bazaar, git, CVS et Darcs. (Si Redmine est un terme inconnu pour vous, c'est un outil de gestion de projet, actuellement utilisé pour l'hébergement de projets proposé par Developpez)

    Après, n'étant pas un utilisateur aguéri d'interface web pour mes dépots, je ne veux pas dire trop de bêtises. Mais il doit forcément exister des outils équivalents à websvn pour Mercurial ou git. Ou sinon, libre à votre imagination d'en créer un

  20. #20
    Membre à l'essai
    Inscrit en
    octobre 2007
    Messages
    17
    Détails du profil
    Informations forums :
    Inscription : octobre 2007
    Messages : 17
    Points : 21
    Points
    21

    Par défaut

    Bonjour,
    en réponse à la question du post:
    oui
    et pourquoi?
    Parce que subversion est répandu et donc accessible en langues et docs par des dev du monde entier. Techniquement il est complet, rien à redire de tigris.

Discussions similaires

  1. Projet PHP / MySQL
    Par hartecel dans le forum Installation
    Réponses: 3
    Dernier message: 06/01/2007, 12h40
  2. [Bonne pratique] Plusieur projets sur un seul serveur Subversion
    Par TitiFr dans le forum Subversion
    Réponses: 1
    Dernier message: 31/05/2006, 11h36
  3. Projet PHP
    Par Nacros dans le forum XMLRAD
    Réponses: 9
    Dernier message: 09/04/2006, 14h46
  4. Réponses: 136
    Dernier message: 27/10/2005, 16h22

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo