Journal Darcs 2.2 release candidate

Posté par .
Tags : aucun
6
11
jan.
2009
Le code source de Darcs 2.2pre2 est disponible en téléchargement [1].

Par rapport à la version 2.1.2 sortie novembre dernier, cette version apporte peu de changements visibles à l'utilisateur. Hormis les corrections de bogues et les améliorations de performance, le plus gros du travail a porté sur la simplification du code et sa portabilité.

Entre temps, il y a eu également un changement important: le concepteur initial David Roundy a laissé sa place au très impliqué Eric Kow [2], et le développement de darcs a eu un coup de fouet grace au Hacking Sprint de fin octobre [3] (un prochain est prévu en mars). Les développeurs impliqués poussent pour que darcs soit mieux modularisé, et réutilise des modules développés par la communauté Haskell. La version 2.2 est l'occasion de sortir une version préliminaire de libdarcs afin d'encourager des projets d'interface graphique se greffant dessus.

darcs est un système de gestion de version distribué, comme git et mercurial donc. Mais il est le seul à gérer les patchs de manière non chronologique, ce qui permet d'échanger librement des patchs indépendants entre dépots, comme le montre cette vidéo [4]. Par conséquent, son utilisation nécessite d'apprendre moins de concepts que git ou mercurial.

Pour les gens qui connaissent les déboires que darcs a eu depuis ses débuts, sachez que les plus gros problèmes furent réglés lors de la version 2 sortie l'année dernière [5]. Cependant, darcs reste largement moins performant que ses homologues plus connus, et n'est donc pas recommandé pour gérer un gros projet, ou un projet contenant des fichiers binaires.

[1] http://lists.osuosl.org/pipermail/darcs-users/2009-January/0(...)
[2] http://lists.osuosl.org/pipermail/darcs-users/2008-November/(...)
[3] http://blog.codersbase.com/2008/10/28/darcs-hacking-sprint-s(...)
[4] http://projects.haskell.org/camp/unique
[5] http://mark.stosberg.com/blog/2008/10/darcs-2-a-major-update(...)
  • # sale temps

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

    J'ai peur que les temps soient durs pour les DVCS alternatifs, git est en train d'occuper tout l'espace et de monopoliser l'attention. ça m'embete un peu parce que j'ai choisi mercurial (après avoir utilisé darcs 1.x un certain temps) et ça serait dommage de le voir progressivement tomber dans l'oubli et être laissé de coté. Pareil pour darcs.

    En plus j'ai moyennement confiance dans les kernel hackers pour faire des outils simples et ergonomiques, git est certainement le plus performant, mais l'approche "couteau suisse" linux-centric, avec 10000 options pour power users ne m'enchante pas plus que ça.
    • [^] # Re: sale temps

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

      Je ne comprend pas ton inquiétude.

      Si git est bien mais trop complexe pour satisfaire tout le monde, alors il n'y a pas de raisons que les autres solutions tombent dans l'oublie.

      Dans le libre si une solution tombe dans l'oublie, c'est que personne n'en avais plus besoin, il n'y a donc aucun regret, d'autant que si le besoin réapparaît ne serait-ce que chez un seul utilisateur il pourra regagner en vigueur.
      • [^] # Re: sale temps

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

        Dans le libre si une solution tombe dans l'oublie, c'est que personne n'en avais plus besoin

        Pas exactement, si une solution tombe c'est qu'il n'y a plus personne pour la maintenir. Il peut rester des utilisateurs (même nombreux parfois) qui s'il n'ont pas l'argent/te temps/la motivation/la compétence se retrouvent "coincés".
        • [^] # Re: sale temps

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

          Tu es coincé quand il plus aucune possibilité ne te permet d'avancer. Avec le logiciel libre, tu n'es jamais coincé, au pire tu manques momentanément de moyens pour avancer, mais rien ne t'empêche de t'organiser pour te donner ces moyens.
          • [^] # Re: sale temps

            Posté par . Évalué à 4.

            RMS !
            Sors de ce corps !!!!!!!
          • [^] # Re: sale temps

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

            Bien sur, rien ne t'empeche d'avancer. Qu'on soit bien d'accord, je suis pro-libre, sans équivoque.

            Mais le libre c'est comme le libéralisme, c'est pas parce que la régulation est théoriquement possible sans intervention (et que ca marche parfois) que ca se vérifie toujours en pratique.

            On peut faire un logiciel libre de merde, on peut faire un virus libre, on peut "planter" une petite communauté de non techniciens voire de non librisites en ne maintenant plus une application.
            • [^] # Re: sale temps

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

              Franchement je vois pas le rapport avec les comparaisons que tu fais. Je n'ai jamais dit qu'un logiciel devenait top moumoute s'il était placé sous licence libre, même si ce logiciel à été conçu avec le pieds et/ou à des fins malveillantes.

              C'est sûr qu'un développeur peu arrêter développer son logiciel libre, mais les utilisateurs ne se retrouvent pas le bec dans l'eau : soit ils ont du temps et la volonté de se retrousser les manches, soit ils paient quelqu'un pour leur fournir du support.

              Si la communauté d'utilisateur dont tu parles ne sont prêt ni à l'un ni à l'autre, c'est qu'il ne méritent pas d'utiliser ce logiciel libre et qu'en fait ils ne sont qu'un attroupement de rapaces qui attendent qu'on leur donne tout sans qu'ils n'apportent rien.
              • [^] # Re: sale temps

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

                Si la communauté d'utilisateur dont tu parles ne sont prêt ni à l'un ni à l'autre, c'est qu'il ne méritent pas d'utiliser ce logiciel libre et qu'en fait ils ne sont qu'un attroupement de rapaces qui attendent qu'on leur donne tout sans qu'ils n'apportent rien.

                Dans le logiciel libre, on est également libre de ne pas participer au développement ;)

                Il peut également se trouver des cas ou l'on a pas la possibilité ni technique, ni financière de faire réaliser le travail. En plus je ne suis pas certain qu'il soit facile de trouver une personne pour "coder le truc" pour pas trop cher (15,20,50 euros). Et si tu fais appel à une SSLL, la note ne vas pas être la même...
                • [^] # Re: sale temps

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

                  Bien sûr que chacun est libre de ne pas participer, je ne pense pas avoir sous-entendu le contraire.

                  Je suis d'accord qu'il peu arriver des moment où l'on a pas les moyens, comme le l'ai dit plus haut il se peu que «tu manques momentanément de moyens pour avancer, mais rien ne t'empêche de t'organiser pour te donner ces moyens».

                  Personnellement, je ne considère pas ça comme un mur infranchissable, tout au plus comme un obstacle plus ou moins difficile à passer sur le parcours.

                  Après chacun son opinion, je ne sais pas si ce qui m'a valut d'être moinsé c'est mon opinion lui même ou le ton avec lequel je l'ai exprimé, mais j'aurais bien aimé plus d'arguments des détracteurs de l'hypothèse que je soutiens.

                  Donc merci pour ta réponse, même si elle n'abonde pas en mon sens.
                  • [^] # Re: sale temps

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

                    C'est peut-être le ton de "ils n'ont qu'a payé" et "ils ne méritent pas d'utiliser le soft".

                    Pour ma part, je préfere largement un logiciel libre non maintenu qu'un logiciel propriétaire en fin de vie (avec les $$ qui vont bien à l'éditeur pour qu'il daigne nous permettre d'utiliser un vieux produit buggé qu'il ne support plus).
                    C'est d'ailleurs plus simple en entreprise que pour un particulier. Une entreprise peut facilement engager un sous-traitant ou une SSLL pour maintenir un soft libre qui n'a plus d'upstream. Par contre, pour les particuliers, ils faut quand même une dose de chance à mon avis (trouver un dev qui accepte de le faire, à moindre coût ou gratuitement).

                    D'ailleurs je ne crois pas qu'il existe un système genre "Perdu de recherche" où une communauté en perdition peut appeler Supercoder pour les sauver en échange d'un slip propre.
    • [^] # Re: sale temps

      Posté par . Évalué à 2.

      Ce qui arriverait serait juste que mercurial aurait besoin du support de git pull/push. Et ce n'est pas impossible y'a des gens qui en discutent en ce moment.
    • [^] # Re: sale temps

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

      Euh bof, si git est bien implémenté chez les linuxiens, dans le domaine du multiplateforme, mercurial l'est bien plus, on le retrouve pour gérer les sources de java, de netbeans, de glassfish, de toute l'arbo de mozilla, de xen, ...

      Devant travailler couramment (voire la plupart du temps) sous windows, j'echangerai volontier mes 50 svn contre des mercurial (et c'est d'ailleurs en cours :P ), qui plus est les plugins mercurial pour les ide sont bien plus mature sur mercurial que sur git à ma connaissance (c'est même fourni par défaut dans netbeans).

      Bref, je suis très loin de partager ton avis sur "git prend tout" !

      Par contre concernant darcs, je souhaite qu'il continue à vivre, néanmoins je n'en ai pas l'utilité, j'espère qu'il trouvera son public :)
      • [^] # Re: sale temps

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

        En fait comme implémentation de git on trouve aussi des client multi-plateformes (java [http://www.jgit.org/] , python [https://code.launchpad.net/dulwich/trunk] ) .

        C'est ce qui fait la puissance de git à mon avis, on le considère comme une spécification avant de choisir un client. Vivement l'intégration de ces nouveaux clients dans les IDEs ( [http://git.or.cz/gitwiki/EclipsePlugin] et [http://code.google.com/p/nbgit/] ) .
        • [^] # Re: sale temps

          Posté par . Évalué à 3.

          Une des faiblesses de git c'est le fait de pas avoir de bibliotheque... En pratique si jgit ou dulwich existe c'est pour pallier l'absence de libgit.

          Sinon le thread qui tourne actuellement sur la ml de mercurial est assez interessant (sur l'interoperabilité hg/git).
          http://article.gmane.org/gmane.comp.version-control.mercuria(...)
          • [^] # Re: sale temps

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

            effectivement y'a plein de choses interessantes dans ce thread.

            En particulier le dernier paragraphe de http://article.gmane.org/gmane.comp.version-control.mercuria(...) (sur le non-merge de mercurial avec bzr) est assez instructif
            • [^] # Re: sale temps

              Posté par . Évalué à 3.

              La partie qui montre que tout les developpeurs "significatifs" de bzr sont employés par canonical peut aussi être inquiétante (surtout quand on connait la fin tragique de arch sous la direction de canonical).
              • [^] # Re: sale temps

                Posté par . Évalué à -1.

                Tout ce que je vois c'est que Bzr est un logiciel libre au sens OSI.

                Le transfert de copyright existe sur nombre de soft (Java et Sun me semble t'il) sur les sources et personne ne trouve à redire.
                On voit le pb qu'il advient dans le cas contraire avec Linux pour le passage en GPL v3

                Sinon tu es au courant aussi que la grande majorité des devs d'Eclipse core sont des devs d'IBM mais ca ne te choque pas

                Donc c'est quoi exactement le risque ?

                Ah oui Canonical le demande pour faire des extensions proprio.
                le demandait semble t'il ? "A few years ago".

                Il parait que Sun ne voulait pas entendre parler de Java Opensource il y a quelques années et aujourd'hui toute leur stratégie est axée dessus.

                Bref si c'est pas du FUD ca !
                • [^] # Re: sale temps

                  Posté par . Évalué à 1.

                  C'est quoi le problème du passage en GPL v3 ? C'est très bien en GPL v2.

                  Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

                  • [^] # Re: sale temps

                    Posté par . Évalué à 2.

                    C'est un autre débat .

                    Il n'empêche que ce changement de license n'est pas possible du fait qu'il faut demander l'avis de tous les auteurs (y compris ceux qu'on ne peut joindre)
                    Ca serait aller vers une BSD, le pb serait le même.
                • [^] # Re: sale temps

                  Posté par . Évalué à 2.

                  Sinon tu es au courant aussi que la grande majorité des devs d'Eclipse core sont des devs d'IBM mais ca ne te choque pas

                  Donc c'est quoi exactement le risque ?


                  Le risque c'est que Canonical décide un jour d'arrêter de financer bzr (comme tla/baz à l'époque) et que comme tous les developpeurs principaux sont employés par Canonical, le support deviennent inexistant.
                  C'est ce qui s'est passé pour baz, Canonical avait repris baz, puis forké sur bzr tout en promettant de continuer à maintenir le projet. Au final ils ont jamais rien fait sur baz, considérant bzr comme plus crucial.
                  Pour Canonical, launchpad étant la pièce maitresse de leur business modele, on peut imaginer que si git devient *le* DSCM de réference ils soient obligés d'y passer, dans ce cas les ressources de bzr risquent de passer entierement sur launchpad+git le business primant sur le reste.

                  Du point de vue des licences ça dépend des opinions, disont que certaines personnes ont été échaudés par l'épisode bitkeeper ("open" source, puis entierement propriétaire avec des licences bien restrictives) pour preferer empêcher tout fork propriétaire du logiciel. Je ne pense pas que ce soit dans l'avantage de Canonical de mettre un terme au developpement open source de bzr, mais le risque est non nul (un rachat ou une faillite dans quelques années est-il totalement improbable ?).
                  • [^] # Re: sale temps

                    Posté par . Évalué à 3.

                    le support deviennent inexistant.
                    C'est le risque pour tout projet libre dans lequel une société s'implique.
                    (Les devs IBM d'Eclipse sont maintenant affectés au projet Jazz)
                    Si le projet meurt c'est simplement qu'il n'était pas viable et ne correspondait pas à une attente. S'il a du potentiel,il sera repris.
                    PAr ailleurs un projet abouti , n'a pas forcément besoin qu'on lui alloue autant de ressources (C'est ainsi qu'IBM justifie la réaffectation de ses devs)

                    pour preferer empêcher tout fork propriétaire du logiciel.
                    Un fork propriétaire n'enlève rien au fait que la version opensource peut continuer d'exister.
                    Sourceforge a forké en proprio et est passé de PHP à Java . C'est ainsi et c'est le jeu.
                  • [^] # Re: sale temps

                    Posté par . Évalué à 1.


                    Du point de vue des licences ça dépend des opinions, disont que certaines personnes ont été échaudés par l'épisode bitkeeper ("open" source, puis entiérement propriétaire avec des licences bien restrictives)

                    Bitkeeper n'a jamais été opensource. Il était gratuit pour ces projets et à changé sa politique.
                    http://fr.wikipedia.org/wiki/BitKeeper
                    Bazaar est un projet GNU sous licence GPL.
                    • [^] # Re: sale temps

                      Posté par . Évalué à 2.

                      D'ou les guillemets, au début le source était disponible (d'ailleurs je suis pas sur que Linus l'aurait choisi si il avait pas pu voir les sources).
      • [^] # Re: sale temps

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

        Le projet Python songe à passer un gestionnaire de sources distribué. Bien sûr, Mercurial est envisagé et semble même en bonne position pour remplacer Subversion. « Bien sûr » car Mercurial est écrit en Python ;-) Bon, je pense que ça prendra encore mois/années et fils de discussions pour migrer complètement à Mercurial. Ça pourrait même ne jamais se faire. En attendant, il y a déjà des développeurs qui l'utilisent pour Python.

Suivre le flux des commentaires

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