Rififi autour de Subversion

Posté par . Modéré par patrick_g.
Tags :
21
2
fév.
2011
Gestion de versions
Le torchon brûle entre les principaux acteurs du projet Subversion : Wandisco d'un côté, Collabnet et la fondation Apache de l'autre !

« Peu de temps avant que nous ne partions tous en vacances de Noël, l'une des entreprises sponsorisant des développeurs dans la communauté Subversion, WANdisco, a envoyé un grand "fu#k you" au reste de la communauté par la voix de son CEO, Dave Richards », écrit Mark Phippard, l'un des principaux contributeurs sur son blog. Contexte : en 2009, le développement du système de contrôle de versions Subversion (SVN pour les intimes) est passé sous l'égide de la fondation Apache, après avoir été mené par Collabnet pendant des années (de nombreux développeurs de Subversion sont employés par Collabnet : C. Michael Pilato, Mark Phippard, Paul Burba ,pour ne citer qu'eux). Wandisco est une autre entreprise fortement impliquée dans le développement de Subversion (nombreux contributeurs, notamment Hyrum Wright, release manager du projet depuis 2008 et aussi « Director of Open Source » chez Wandisco). Ces deux entreprises vendent des produits et services articulés autour de Subversion.

Dans une dépêche plutôt hostile et mensongère publiée fin 2010, dans laquelle il dénonce la lenteur du projet en des termes assez crûs (« certains contributeurs sans scrupules n'hésitent pas à faire des changements triviaux dans de larges fichiers, juste pour avoir de meilleures statistiques »), Dave Richards (CEO de Wandisco) annonce que son entreprise se résigne à faire le boulot nécessaire pour implémenter les fonctionnalités attendues depuis trop longtemps par les utilisateurs (notamment, améliorer le système de fusion). « Enough is enough », écrit-il. Sous-entendu : Collabnet qui portait le projet jusque-là n'était pas à l'écoute des utilisateurs. Coup marketing évident.

Cette dépêche a suscité de nombreuses réactions de la part des acteurs mis en cause, réactions allant de la déception à la moquerie : c'est Mark Pippard qui fait remarquer que WANdisco a déjà fait le coup de la dépêche de presse il y a un an, pour annoncer de nouveaux super-développements autour de Subversion : SubversionJ et Obliterate, deux développements qui n'ont jamais vraiment commencé.

Les relations sont maintenant tendues, et Wandisco ne semble pas vouloir assumer un fork, puisque l'entreprise essaie maintenant de se rabibocher ouvertement avec la fondation Apache (dans une nouvelle dépêche publiée aujourd'hui, ils se réjouissent d'être devenus sponsor officiel de la fondation).

Il sera donc intéressant de voir comment la situation évolue, notamment en ce qui concerne la sortie prochaine de Subversion 1.7, toujours prévue pour début 2011 et impliquant des développeurs issus de toutes les parties concernées. Cette nouvelle version doit apporter à Subversion des améliorations au niveau de la couche HTTP et de la gestion de la copie de travail, premiers pas vers des fonctionnalités distribuées à la Git.
  • # donc si je comprend bien

    Posté par . Évalué à 10.

    Une boite dis "merde, les developpements qui nous intéresse/qui intéresse les utilisateurs ne sont pas fait.
    On va les faires".

    Au milieu il y a une pique ou deux, il se fait mousser une ou deux fois, ok.

    Mais honnêtement ça n'a rien de particulièrement "fort", surtout quand on a déjà vu la prose de linus.

    Et derrière on a une entreprise et une fondation qui dit "non mais comment osez vous coder sur un projet open source.
    De toute façon vous êtes rien" (je cite : No one knows or cares who WANDisco is ; If you are so desperate for attention

    Bref, sans vouloir être vexant, niveau com je préfère quand même wandisco.

    Quand on joue les vierges effarouché, il en faut pas en même temps avoir exactement le même comportement que ce qu'on reproche (et NON le coût du "c'est l'autre qui a commencé" ca marche en primaire, mais pas pour des gens un minimum évolué).


    Bref, pour moi un non évenement, qui c'est transformé en affaire de part la susceptibilité de part et d'autres (oui il y a des cons qui s'amuse a jouer au con (commits inutiles, communiqué de presse avec des piques inutiles, lettre ouvertes pleine de sarcasme inutiles).
    • [^] # Re: donc si je comprend bien

      Posté par (page perso) . Évalué à 10.

      A mon avis ces boites sont nerveuses car elles s'aperçoivent qu'elles ont misé sur le mauvais cheval en choisissant Subversion et qu'elles vont se faire déboulonner par Git.

      Hop un petit GOTO vendredi !
      • [^] # Re: donc si je comprend bien

        Posté par (page perso) . Évalué à 10.

        Je cite : "premiers pas vers des fonctionnalités distribuées à la Git."

        Mouhaha, dédicace à tout ceux qui critiquent Git pour sa décentralisation.

        (Ici git la tombe de SVN)

        « En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll

  • # c'est pas franchement grave

    Posté par . Évalué à 7.

    A peu pres tous les projets libres sont en train de migrer vers des trucs un chouilla plus moderne que subversion tel que Git, mercurial ou bazaar.
    Ce genre de nouvelle aurait pu etre "inquietante" a l'epoque de CVS ou subversion mais bon aujourd'hui c'est plus amusant qu'autre chose...

    Desole pour les fans de subversions mais bon le vents a tourne.
    • [^] # Re: c'est pas franchement grave

      Posté par (page perso) . Évalué à 1.

      +1 subversion n'a plus vraiment d'avenir à côté de git et mercurial
      • [^] # Re: c'est pas franchement grave

        Posté par . Évalué à -4.

        Surtout à côté de Git.
      • [^] # Re: c'est pas franchement grave

        Posté par (page perso) . Évalué à 2.

        Oui, ça n'a pas vraiment de sens te tenter de le faire évoluer. De par son architecture il gérera toujours moins bien les branches et sera toujours ultra lent, sauf à tout refaire.

        À la limite quelques fonctions sympa comme stash ou une queue de commits, histoire de le rendre sa fin de vie moins douloureuse.

        DLFP >> PCInpact > Numerama >> LinuxFr.org

        • [^] # Re: c'est pas franchement grave

          Posté par . Évalué à 2.

          Dans ma boîte on est en train de passer de cvs à svn, et c'est le gros bordel... enfin c'est surtout le code et la palanquée de branches qui pose problème, et notamment le fait que pour gérer un bronx pareil des surcouches ont été développées sur cvs et svn.

          Malgré l'enthousiasme autour de git, je n'ai pourtant pas l'impression que git pourrait convenir dans notre cas : en gros le repository principal contient une série de répertoires, chacun étant un module, par ex a, b, c... et ce repository a été branché un tas de fois, par ex 1, 2, 3... maintenant, les nouvelles branches utilisent certains modules des autres branches : par ex la branche 26 va contenir a_26, b_15, c_20, d_26, e_13. Le tout est bien sûr géré par ces surcouches, des scripts qui vont s'occuper de faire des check outs de chaque module depuis la branche indiqué dans un fichier de config.

          Bon, le fait est que cvs et svn ne sont eux même pas capable de gérer ça tout seul, mais j'ai l'impression qu'ils conviennent mieux que git qui n'est pas capable (enfin je crois) de gérer seulement un sous répertoire extrait d'une branche.
          • [^] # Re: c'est pas franchement grave

            Posté par (page perso) . Évalué à 2.

            Oui git implique de tout récupérer.
            La solution peut être de faire un repo git par dossier, et ensuite avoir un repo maître qui utilise les submodules. Dans tous les cas tu vas avoir tout un tas de scripts autour…

            DLFP >> PCInpact > Numerama >> LinuxFr.org

          • [^] # Re: c'est pas franchement grave

            Posté par (page perso) . Évalué à 2.

            Ça m'a l'air d'un beau bordel, votre dépôt de code… Honnêtement je ne comprends pas.
            • [^] # Re: c'est pas franchement grave

              Posté par . Évalué à 8.

              Tu es encore loin de tout imaginer... :)
              - les qqs fichiers .c de 50.000 lignes (au milieu de centaines d'autres), gérés manuellement bien sûr...
              - certaines struct de plus d'un millier de lignes
              - les historiques cvs tellement gros que 90% des outils plantent. Avec une version patchée de cvsgraph, j'ai quand même réussi à générer un png de 20.000x30.000 pixels
              - les makefiles imbriqués dans tous les sens, en général une dizaine d'appel des uns aux autres suite à un make, (et rien à voir avec un makefile par répertoire)
              - l'enfer des #ifdef dans tous les sens
              - le code « romifié », çad que une grosse partie du code compilé est déjà dans la ROM des produits et est donc supprimée lors du link... va comprendre pourquoi tes modifs ne changent rien...
              - des développeurs répartis sur toute la planète, des mailing lists qui croulent sous les rapports d'outils de build et de tests automatisés, et sur les annonces de tag (« je vais taguer telle branche, suspendez les commits »)
              - et le petit détail qui tue sur lequel je suis tombé il y a qq jours : il y un connard qui a rentré comme commentaire de commit un message sur une dizaine de ligne reprenant le format exact de la sortie de cvs log... bluffant... après des heures de debug sur un script qui plantait, j'ai encore mis 10mn à identifier dans le log le début et la fin exacts du commentaire foireux.
          • [^] # Re: c'est pas franchement grave

            Posté par . Évalué à 3.

            Si j'essaie de comprendre, ca ressemble à la gestion par composant.
            i.e que tu définis des articles de configuration qui ne sont pas de simples fichiers et qui obéissent à leur propre cycle de vie.
            C'est le pendant coté GCL de l'architecture à base de composants
            http://en.wikipedia.org/wiki/Component-based_software_engine(...)

            Ton application est un simple assemblage de plusieurs versions de composants.
            Un composant peut être réutilisable dans plusieurs projets différents, modifiable ou non dans le projet.
            On est soit fournisseur, soit consommateur du composant.
            Si c'est un composant binaire et que tu es consumer et que tu n'a pas besoin de faire évoluer les sources tu t'en sors avec des outils comme Maven et un VCS est superflu sinon c'est utile.

            UCM et Clearcase gère ça pas trop mal.
            SVN le fait grâce au svn copy ("cheap copies") et aux svn:externals

            Avec mercurial il faut utiliser le submodules et il doit y avoir un équivalent sous Git.

            http://stackoverflow.com/questions/2479274/using-mercurial-i(...)
    • [^] # Re: c'est pas franchement grave

      Posté par . Évalué à 6.

      sans parler d'être fan ou pas, les entreprises sont toujours en retard sur ce qui se fait de mieux sur le plan technologique, alors, certes, les projets libres migrent, mais il reste encore du monde sous subversion pour quelques années.
      Ici, on utilise toujours CVS d'ailleurs ...
      • [^] # Re: c'est pas franchement grave

        Posté par (page perso) . Évalué à 6.

        Vous venez de migrer depuis ClearCase, c'est ça ?


        Je connais pas mal de boîte où les "geeks" de service font de la promotion de Subversion comme l'outil moderne à la mode. Les conservateurs eux, sont plutôt Clearcase ou envoi de zip sur des FTP (oui oui, je suis sûr que le code de votre micro-onde/lave-vaisselle/voiture est développé comme ça).
        • [^] # Re: c'est pas franchement grave

          Posté par . Évalué à 5.

          non, là, c'est juste du CVS depuis plus de 10 ans (enfin je pense, j'y étais pas à l'époque). Heureusement, on échappe pour l'instant à source safe et autres pvcs.

          Mais dans mon premier boulot, j'avais mis en place un CVS pour remplacer la méthode cpold, qui offrait pourtant déjà la possibilité de remonter jusqu'à la version N-1 !! \o/

          Bon, je suis un peu médisant, cpold était couplé à rccs ...
        • [^] # Re: c'est pas franchement grave

          Posté par . Évalué à 2.

          Tiens concretement, on est en train de deployer du git au taf. Certains de mes collegues sont des habitues de Clearcase mais pour autant j'ai du mal a leur faire voir les bons points de git.

          Je ne connais pas du tout Clearcase, avez vous des elements de comparaison avec git ?
          • [^] # Re: c'est pas franchement grave

            Posté par . Évalué à 1.

            Malheureux... J'ai moi meme fait l'experience de former a git mes collègues habitues a clearcase.
            C'est plus compliqué que de le faire a des gens qui n'ont jamais fait de VCS.
            Le plus dur est leur faire comprendre qu'il ne faut surtout pas faire d'analogie, ou essayer de retrouver des methodes de travail.
            Ca n'a rien a voir. Point. Le workflow est complètement different.

            cc travaille sur des fichiers (et des repertoires), git travaille sur un repo complet et coherent.

            La notion de branche n'a rien a voir.

            "checkout" a une sémantique complètement differente.

            J'en passe...
            • [^] # Re: c'est pas franchement grave

              Posté par . Évalué à 6.

              En même temps ce n'est pas à l'homme de s'adapter au worklow de l'outil mais à l'outil de s'adapter au cycle de vie du projet.

              Les habitués de CC sont plus difficiles à convaincre simplement parce qu'ils savent maitriser un VCS digne de ce nom qui sait gérer des branches efficacement et merger sans se tromper. Ceux qui ont toujours défendu CVS et SVN face au vilain proprio m'ont toujours fait marrer:

              - Les vues dynamiques qui te permettent de browser le dépôt sans le cloner avant
              - possibilité de bosser en lock pessimiste ou optimiste
              - les clones existent depuis toujours avec en plus des branches qui ne sont pas propres à un user mais dont la maitrise peut être transférée
              - les tags sont des objets à part entière pas comme SVN
              - les attributs qui font encore la pige aux properties de SVN
              - le rename tracking
              - les triggers sur plein de commandes qui permettent de le customiser à sa sauce


              Bref il tient encore bien la comparaison avec Git et Hg


              Mais aujourd'hui il a 20 ans, le monde à évolué et il montre ses lacunes
              - privilèges d'accès lié à l'OS
              - protocole verbeux
              - plage de port au lieu d'un seul
              ....
              C'est un outil adapté au travail en LAN mais beaucoup moins au travail distant
              • [^] # Re: c'est pas franchement grave

                Posté par . Évalué à 2.

                > En même temps ce n'est pas à l'homme de s'adapter au worklow de l'outil mais à l'outil de s'adapter au cycle de vie du projet.
                Pas d'accord les VCS ont chacun un ensemble de fonctionalités qui orientent le workflow de manière vraiment importante. Si on veut être efficace, il faut aller dans le sens du workflow de l'outil.

                Cela dis, je ne critique pas du tout le workflow de cc. Les idées qu'il y a dedans sont vraiment bien.

                C'est juste que c'est mega lent, qu'il faut une équipe complète d'admin pour gérer un serveur pour 50 personnes.

                Maintenant on a un gitorious qui a pris une semaine a installer (sans être spécialiste IT ni connaitre RoR avant), et a configurer pour nos besoin, et ca tourne tout seul.
                • [^] # Re: c'est pas franchement grave

                  Posté par . Évalué à 4.

                  C'est là où tu te trompes.

                  CC permet justement de s'adapter à quasiment tous les workflows de projet et est customisable à partir de sa version de base.
                  Tu peux utiliser un workflow prêt à l'emploi avec la surcouche UCM.

                  Avec Git, c'est la même chose, simplement il faut s'investir pour définir clairement son besoin.

                  Les spécificité des outils ne doivent intervenir qu'à la marge sinon c'est que l'outil n'est pas adapté.


                  Ton exemple montre juste que tu veux un truc prêt à l'emploi auquel cas il faut effectivement changer ses habitudes.
                  Si tu as affaire à un rejet il faut peut-être prendre le temps de comprendre le besoin et mettre en oeuvre une vraie conduite du changement. La Rache a ses limites (mais peut-être que vous n'êtes pas nombreux)


                  C'est juste que c'est mega lent, qu'il faut une équipe complète d'admin pour gérer un serveur pour 50 personnes.

                  Pour la lenteur je te donne pas tort (le poids de l'âge).
                  Pour l'équipe d'admin, c'est encore un pb d'organisation.
                  Chez nous une équipe de 3 admin gère une DSI de plusieurs centaines de développeurs en ayant proposé un worklow et un toolset associé.
                  Après on nomme un responsable GCL (un dev senior) par projet qui s'occupe de mettre en oeuvre le workflow et de coacher lorsque les devs de base en ont besoin. L'admin au sens propre: coté client et serveur + méthode + support ne monopolise que 3 ressources.
          • [^] # Re: c'est pas franchement grave

            Posté par . Évalué à 9.

            * Ne pas attendre 1 semaine qu'un admin te crée un compte sur le serveur
            * ne pas attendre 15s avant de pouvoir commencer à éditer un fichier
            * ne pas râler après Gaston qui est parti en vacances sans relâcher ses fichiers
            * ne pas attendre 10 mns pour se créer une vue et une config spec et commencer à bosser sur un patch urgent
            * ne pas se retrouver avec la moitié de son changeset commité et casser le build (transaction atomique), quoique UCM avec un projet multistream (rebase/deliver) revient exactement au même que Git avec push mais alors quelles emmerdes par ailleurs (gestion des baselines foiireuse, ...)
            * poser un tag en 5 secondes
            * branches locales
            * Pouvoir bosser et commiter à la maison sans pb
            * S'interfacer avec tous les outils open source ou cheaps de la planète et ne pas se limiter à Clearquest ou Jazz (integration JIRA=>Fisheye +Tasktop pas terrible, Hudson= galère, ..)
            * suivre l'historique de ton projet et pas seulement au niveau du fichier (UCM pallie par contre)
            * avoir un DSI heureux de ne pas gaspiller des dizaine de Keuros par an et acheter du super matos à la place
            * Pouvoir bosser avec une boite exterieure sans que ce soit insurmontable (avec CC multisite obligatoire, ceux qui auront tenté de convaincre de mettre en place du multisite comprendront, .... ouvrir une plage de ports au lieu d'un seul port, qui paye les licences ? gestion du mastership, alignement des version des serveurs, ...)
            * git bisset
            * star merge
            ...

            Par contre tu auras du mal à convaincre ceux qui aime la securité du reserved checkout (usage basique pour quelques scripts), de convaincre que le merge git de base est mieux que le merge 3 ways de CC
            (le rename tracking se fait sur le hash et tente de deviner quand un fichier est renommé ce qui ne gère pas certains cas).

            Y'en aurait encore à dire, je ferai un petit journal un de ces 4
        • [^] # Re: c'est pas franchement grave

          Posté par . Évalué à 5.

          mais voyons ce n'est pas réservé aux micro-onde/lave-vaisselle/voiture !
          les centrales nucléaires aussi ! mets un scm entre les mains de mes collègues et tu verras que pour eux c'est une usine à gaz destinée à les rentre contreproductifs. un jour un a décidé de demander un "patch" à son éditeur, il n'a pas su quoi faire avec le fichier que celui-ci a envoyé.
      • [^] # Re: c'est pas franchement grave

        Posté par . Évalué à 2.

        Exactement, svn c'est génial!

        Les entreprises sont à peu près réceptives à subversion ou l'utilisent déjà, et ça permet de faire du git-svn dans son coin ;)
      • [^] # Re: c'est pas franchement grave

        Posté par (page perso) . Évalué à 2.

        FreeBSD et OpenBSD sont développés avec CVS. D'ailleurs, CVS est aussi nécessaire sur le poste client pour utiliser les ports FreeBSD non ?
        http://wiki.freebsd.org/VersionControl

        Tiens, il semble d'ailleurs que l'OS plus libre que libre (FreeBSD) utilise d'ailleurs un logiciel proprio en plus pour gérer son code : Perforce.
        • [^] # Re: c'est pas franchement grave

          Posté par . Évalué à 2.

          OpenBSD utilise OpenCVS.

          Et oui: comment réécrire un concept dépassé. M'enfin bon, ils disent que ça répond a leur besoin, tant mieux pour eux.
          Le problème c'est que d'autres personnes les croient et continue a utiliser CVS grâce a eux (a cause d'eux?).

          Tiens, il semble d'ailleurs que l'OS plus libre que libre (FreeBSD) utilise d'ailleurs un logiciel proprio en plus pour gérer son code : Perforce.
          Du moment que tout le monde n'est pas forcé de l'utiliser (puisque c'est en plus), alors ça ira.

          Quand Linux utilisait exclusivement BitKeeper, c'était quand même plus gênant.
        • [^] # Re: c'est pas franchement grave

          Posté par (page perso) . Évalué à 2.

          FreeBSD et OpenBSD sont développés avec CVS.

          FreeBSD utilise SVN depuis quelque temps déjà (deux ans ?)

          D'ailleurs, CVS est aussi nécessaire sur le poste client pour utiliser les ports FreeBSD non ?

          Le SVN est "mappé" vers CVS pour pouvoir utiliser les outils existants (en attendant de les remplacer). En général on utilise csup/cvsup pour récupérer les sources ou les ports.


          Tiens, il semble d'ailleurs que l'OS plus libre que libre (FreeBSD) utilise d'ailleurs un logiciel proprio en plus pour gérer son code : Perforce.


          Perforce contient seulement des branches expérimentales. Par exemple c'est là que sont stockés les Googles Summer of Code. Je ne sais pas pourquoi ils avaient choisi perforce, mais c'était déjà en place bien avant le SVN.

          les pixels au peuple !

          • [^] # Re: c'est pas franchement grave

            Posté par (page perso) . Évalué à 4.

            En fait, P4 (non libre), a décidé de contribuer à sa façon au projet FreeBSD en mettant ses outils à dispositions des devs qui le souhaitent, pour les développements externes au dépôt officiel (sous SVN). Mais son utilisation n'a rien d'obligatoire, et beaucoup préfèrent utiliser Hg ou git ou que sais-je encore...
  • # merge et rename tracking

    Posté par . Évalué à 7.


    annonce que son entreprise se résigne à faire le boulot nécessaire pour implémenter les fonctionnalités attendues depuis trop longtemps par les utilisateurs (notamment, améliorer le système de fusion)


    http://subversion.apache.org/roadmap.html


    Q1 2011 Branch 1.7.x 1.7.0 feature-complete
    ...
    Q1 2012 Release 1.8.0 repository-dictated config; tree conflicts improvements; rename tracking;


    rename tracking issue
    =>
    Sous Apache
    http://subversion.tigris.org/issues/show_bug.cgi?id=3631
    => rename issue tracking ala SVN =>
    Sous Tigris
    http://subversion.tigris.org/issues/show_bug.cgi?id=898

    Opened: Wed Sep 11 01:42:00 -0800 2002
    ...
    "Absolutely must" ? This sounds like a feature which can be postponed
    until after 1.0.

    ...

    ------- Additional comments from Peter N. Lundblad Fri Sep 23 04:33:46 -0800 2005 -------

    Moving to 1.4, since, while cmpilato has started this work on the fs-atomic-
    renames branch, it won't be merged before 1.3.

    ...
    ------- Additional comments from Peter N. Lundblad Tue May 2 01:14:02 -0800 2006 -------

    The 1.4 branching point is approaching and this is not happening before that,
    so move into 1.5-consider.

    ...
    ------- Additional comments from Erik Huelsmann Wed Apr 4 08:50:16 -0800 2007 -------

    With resources fully concentrated on Merge Tracking, I don't think having this
    in 1.5 is viable. Moving to 1.6-consider.

    ....

    ------- Additional comments from Hyrum K. Wright Tue Mar 10 06:45:10 -0800 2009 -------

    Post-1.6 issue sweep. Since 1.7 is already shaping up to be a large release,
    move to 1.8-consider.



    and now ? reported à la 1.?.? nom de code "Saint Glin Glin"

    rename tracking kezako ?

    1- créer un fichier foo.c sur le tronc et commiter
    2- brancher
    3- renommer foo.c en baz.c dans la branche.et commiter
    4- editer foo.c dans trunk et merger dans la branche
    ....
    Tadaaaa

    compute ~~~~ SVN,~~~~ Failed ~~~~Git~~~~ Success ~~~~ Hg ~~~~ Success~~~~
    Enjoy !!!!

    Imaginez la joie de ceux qui se lancent dans un refactoring sous eclipse en renommant des classes ou des packages en utilisant plusieurs branches,(obligé de le rélancer dans tous les projets) vous comprendrez pourquoi l'intégration continue a de beaux jours devant elle avec un outil qui est incapable de merger correctement.
  • # Belle évolution

    Posté par (page perso) . Évalué à 6.

    En tout cas on peut noter une belle évolution de la population linuxfriènne.

    Il y a 10 ans le troll de base concernait les éditeurs de texte, les environnements de bureau.

    Avec la maturité du lectorat, emacs et gnome ont gagnés et le troll à la mode survient sur les outils de dev.

    Dans 10 ans, quand git et hudson auront gagnés, trollera-t'on sur CMMi vs Scrum ?
    • [^] # Re: Belle évolution

      Posté par . Évalué à 10.

      Ben, la réponse est simple: emacs gagnera comme éditeur de texte, environnement de bureau, système de gestion de versions, ide, intégrateur continu, navigateur web, client mail, calcul formel, calcul numérique, moteur d’aide à la décision, sgbddr, base nosql, outil de monitoring de fermes de calcul, erp, modélisation de processus, simulation de circuits électronique, crm, émulateur de terminal, player multimedia, aggrégateur rss et même firewall.
      (oui, c’est un troll : il faut bien reconnaître qu’au niveau éditeur de texte, emacs, c’est pas encore ça)
    • [^] # Re: Belle évolution

      Posté par (page perso) . Évalué à 7.

      Hudson ? Ça m'étonnerait que l'on connaisse encore un projet de ce nom dans 10 ans ;-)
    • [^] # Re: Belle évolution

      Posté par . Évalué à 4.

      Mais non, pour les p’tit nouveaux qui veulent se faire la main, un indécrottable : windows versus GNU/Linux.

      Le problème des VCS, c’est qu’on finit tous par tomber d’accord sur git.
    • [^] # Re: Belle évolution

      Posté par . Évalué à 3.

      "Wtrollera-t'on sur CMMi vs Scrum ? "
      La Rache a déjà gagné...
  • # Wandisco ne semble pas vouloir assumer un fork

    Posté par . Évalué à 10.

    Tu m'etonnes, ils savent qu'apres ils pourront pas merger !
    • [^] # Re: Wandisco ne semble pas vouloir assumer un fork

      Posté par (page perso) . Évalué à 2.

      C'est surtout qu'ils se sont fait rappelés a l'ordre au sujet de l'utilisation de la marque Subversion.
      • [^] # Re: Wandisco ne semble pas voulo

        Posté par . Évalué à 0.

        Not true. Being good corporate citizens, WANdisco are the first Subversion corporate sponsor to adhere to the trademark use guidelines. We are doing this voluntarily. It would be nice if other referred to Subversion as "Apache Subversion" in their marketing.

        We are making great strides on the Apache Subversion project. For instance Philip Martin, one of our Subversion commiters reported and fixed the security release for Subversion 1.6.16. We are also updating progress on our Blogs for the promised work around branching and merging.

        I am very pleased that some of you have correctly spotted the FUD / misinformation from a certain company we compete with...

  • # FFmpeg...

    Posté par (page perso) . Évalué à 4.

    • [^] # Re: FFmpeg...

      Posté par (page perso) . Évalué à 3.

      Une dépêche, ou un journal au moins, à ce sujet !

      Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

      • [^] # Re: FFmpeg...

        Posté par (page perso) . Évalué à 2.

        Avec quelques explications, j'ai un peu lu les discussions, mais sans le bagage de l'historique on a un peu de mal à suivre...
        • [^] # Re: FFmpeg...

          Posté par (page perso) . Évalué à 2.

          Bah Attila Kinali écrit "First i want to give you a warm FUCK YOU ALL! for what you've written and done the last few days." C'est clair non ? :-)
    • [^] # Re: FFmpeg...

      Posté par (page perso) . Évalué à 3.

      Wow... J'espère qu'un passionné pourra fournir un résumé, car la je ne comprend rien du tout à la bataille. Un patrick_g pour suivre les trolls ffmpeg plutôt que kernel?
  • # J’y crois pas

    Posté par . Évalué à 2.

    « crûs », c’est le verbe croître à l’imparfait du subjonctif…

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.