Et Linus?

• [^]Re: Et Linus?

  Posté par Matthieu Moy (page perso, ) le 06/04/2005 à 07:33. (lien). Évalué à 1.

  C'est richard qui l'a convaincu ;-)

  • [^]Re: Et Linus?

    Posté par Fabien Penso (Jabber id, page perso, ) le 06/04/2005 à 08:09. (lien). Évalué à 1.

    Va -til choisir arch ou svn, ou un autre ? :-) Je suis curieux de voir ce qu'il va choisir.

    --
    blog them all :: la photo du jour
    Je vote pour LinuxFr en Rails !

    • [^]Re: Et Linus?

      Posté par Marc (Jabber id, page perso, ) le 06/04/2005 à 08:19. (lien). Évalué à 3.

      svn je doute, il cherche plutôt un truc distribué et il me semble que ce n'est pas le cas pour svn.
      Par contre tla/baz/baz-ng collent plus je pense. D'ailleurs, je crois que certains dev de GNU arch font partis du panier de "mauvais garçon" dont Larry parle (je retrouve plus, mais j'étais tombé sur un échange de mail entre larry et un dev de arch il me semble, assez sympatique)

      • [^]Re: Et Linus?

        Posté par Matthieu Moy (page perso, ) le 06/04/2005 à 09:02. (lien). Évalué à 2.

        > svn je doute
        
        Y'a svk basé sur svn et qui a l'air pas mal. Jamais essayé.

    • [^]Re: Et Linus?

      Posté par NebuchadnezzaR () le 06/04/2005 à 08:24. (lien). Évalué à 0.

      GNU Arch, sans aucun doute ;-)
      
      GNU Arch, c'est bon mangez-en

      • [^]Re: Et Linus?

        Posté par Matthieu Moy (page perso, ) le 06/04/2005 à 08:46. (lien). Évalué à 6.

        > GNU Arch, c'est bon mangez-en
        
        Si par "GNU Arch", tu entends tla, soyons clairs : Une organisation sérieuse n'investira *jamais* dans tla. Une "équipe" de dev même pas capable de dire ou est son bugtracker, qui sort régulièrement des version rcX ou pre-Y sans qu'elles aboutissent sur des versions stables (un truc rigolo est de suivre l'historique du "partial undo". Le code a été écrit il y a a peu près un an, il a été mergé deux fois dans la branche supposée principale, mais les deux fois, cafouillage et recommençage a zero - on peut toujours attendre). Un développement capable de passer au point mort complet pendant des mois, de mettre 3 ou 4 mois a corriger une faille de sécurité. Un mainteneur qui considère qu'ajouter un cache a tla serait une "bloated feature", ...
        
        Par contre, du coté de baz, il y a pas mal d'espoir. D'autant que c'est supporté par canonical, qui ne nous a pas habitué a faire de la merde ...

        • [^]Re: Et Linus?

          Posté par Marc (Jabber id, page perso, ) le 06/04/2005 à 08:56. (lien). Évalué à 4.

          Ouaip, et y'a baz-ng qui semble repensé. D'après ce que j'ai lu, il semble que certains dev soient plutôt bon. Au final, ça sera peut etre bien, mais ça sera jamais prêt pour Juillet ;)

          • [^]Re: Et Linus?

            Posté par champi (page perso, ) le 06/04/2005 à 09:57. (lien). Évalué à 4.

            bzr (Bazaar-ng) ne sera surement pas viable en prod pour juillet mais ca avance vraiment vite (recu aujourd'hui dans ma BAL) :
            
            

            
            [please forward to whoever you think is interested]
            
            In the last few weeks:
            
            * File-rename operations work.
            
            * Reinstated the integrity checker.
            
            * I was accepted to do a talk about bazaar-ng at LCA05 and I started
            preparing it.
            
            * I made three bzr releases, and got the web site and mailing list
            running. About five people have sent back patches, mostly for
            portability problems.
            
            * I did a lot of benchmarks on kernel trees. I think bazaar-ng is
            approximately the fastest tool at the moment (but I haven't done
            rigorous comparisons). At any rate it is fast enough.
            
            * I demonstrated it to kernel and gcc hackers, who have been favourably
            impressed with the speed, simplicity and friendliness and are on my case
            to get it ready for them.
            
            * I've written some blog entries with more detail here:
            http://sourcefrog.net/weblog/software/vc/bzr(...)
            
            * Much exchange of design ideas with Robert, who is adding -ng ideas to
            baz at a very impressive rate.
            
            * Improved argument handling (e.g. can do "cd lib && bzr add foo.c" and
            "bzr commit --help")
            
            Before LCA I want to:
            
            * Do remote clone operation.
            * Do simple mergers.
            * Prepare a good talk.
            

            • [^]Re: Et Linus?

              Posté par anonimulo () le 06/04/2005 à 10:55. (lien). Évalué à 4.

              Ca anvance non seulement vite, mais en plus dans la bonne direction.
              Je viens de lire son Opportunities for improvement on GNU Arch(1) et je suis très impressioné, il a les idées très claires sur ce qui doit être fait. J'étais très impressioné par GNU Arch, qui recèle un nombre d'idées brillantes très au-dessus de la moyenne (la première partie du document (1) ), mais il y a avait quelquechose qui ne tournait pas très rond dans son implémentation et son interface utilisater, sans que je sois capable de dire précisément quoi. Là il se propose d'éliminer beaucoup de la mauvaise graisse qui s'était accumulé sur le projet, ca devait devenir très bon.
              
              (1) http://www.bazaar-ng.org/doc/todo-from-arch.html(...)

          • [^]Re: Et Linus?

            Posté par Matthieu Moy (page perso, ) le 06/04/2005 à 11:20. (lien). Évalué à 5.

            > il semble que certains dev soient plutôt bon.
            
            Le principal dev, c'est Martin Pool, auteur de distcc et rsync, c'est déjà plutôt bon signe.

    • [^]Re: Et Linus?

      Posté par Matthieu C () le 06/04/2005 à 08:26. (lien). Évalué à 3.

      . In fact, Linus has already begun working on a simplistic tool that takes advantage of Linux performance features. This effort has been aided by Larry, who added that it was also good for BitMover, as a Linux-only tool would not be competition to BitKeeper, whose largest market is on Windows.
      
      Ca ce trouve il va se faire sa moulinette, un peu comme il avait avec sparse...

Darcs

• [^]Re: Darcs

  Posté par Marc (Jabber id, page perso, ) le 06/04/2005 à 08:20. (lien). Évalué à 2.

  une rapidité déconcertante
  J'ai pas testé, mais tous le monde ne semble pas d'accord...
  
  "Larry noted that Linus tried monotone, but a simple import of flat files without versioning information took 2 hours, far too slow. The same was true for Darcs."

  • [^]Re: Darcs

    Posté par JPz (page perso, ) le 06/04/2005 à 08:28. (lien). Évalué à 1.

    Je parlais de la rapidité de prise en main ... :-)
    
    Il semble en effet que Darcs ait quelques défauts sur le get (<=> checkout) de gros projets, mais l'auteur bosse sur l'amélioration de cette nuisance.

    • [^]Re: Darcs

      Posté par Matthieu Moy (page perso, ) le 06/04/2005 à 08:38. (lien). Évalué à 2.

      Le problème de darcs, c'est qu'il a besoin de charger tout l'historique du projet pour un certain nombre de commandes. Donc, c'est inenvisageable sur des gros projets. Par contre, ce qui est extraordinaire, c'est que pour contribuer a un projet existant, il suffit de faire
      
      [ apt-get install darcs ]
      darcs get ...
      [modif]
      darcs record -a
      darcs send
      
      Et hop, avec 3 commandes, j'ai envoyé un patch !! (même pas la peine d'ouvrir mon mailer, même pas besoin d'avoir les droits sur le repository principal)

      • [^]Re: Darcs

        Posté par JPz (page perso, ) le 06/04/2005 à 09:19. (lien). Évalué à 1.

        Il me semble que l'on peut explicitement demander à ne pas charger toute l'historique (à vérifier). Le problème est surtout que c'est chargé intégralement en mémoire, d'où le problème de passage à l'échelle.
        
        Sinon j'avais essayé GNU Arch avec plein de bonne volonté, mais je n'ai jamais accroché (trop compliqué). Sur ce coup là ton collègue Jérôme ne m'a pas converti ;-)

tla

• [^]Re: tla

  Posté par Matthieu C () le 06/04/2005 à 08:37. (lien). Évalué à 4.

  j'ai retrouve le lien : http://arch.debian.org/docs/linux/html/tlalinux.limitations.html(...)

  • [^]Un peu hors sujets

    Posté par ferveuol () le 06/04/2005 à 09:45. (lien). Évalué à 1.

    Juste pour le faire connaitre "Libresource". Il s'agit plutôt d'une alternative de SourceForge. Il est développé par le laboratoire du Loria. Encore en face de test, il n'est pas encore concevable de l'utiliser en production. A surveiller cepandant:
    http://www.libresource.org/fr/(...)

• [^]Re: tla

  Posté par Matthieu Moy (page perso, ) le 06/04/2005 à 09:35. (lien). Évalué à 2.

  Pour le cache, baz (un fork de tla) a un système de cache. tla a quelque chose qui ressemble fort au cache (revision library, mirroir local) sans en être vraiment un.