Arch: un programme de gestion de version prometteur.

Posté par  (site web personnel) . Modéré par Sylvain Rampacek.
Étiquettes :
0
9
juil.
2003
GNU
Dans le monde du Logiciel Libre, CVS/RCS est un outil qui a su se rendre indispensable pour gérer le travail collaboratif de plusieurs développeurs en parallèle. Cependant, ce logiciel montre bien vite ses limites quand il s'agit de développements distribués et fortement axés sur l'usage de branches.

Des alternatives pointent le bout de leur nez, une des plus prometteuses: Arch. Elle résout bon nombre de problèmes inhérents à CVS/RCS et surpasse déjà Subversion en termes de fonctionnalités. L'utilisation d'outils de versionning est une des clefs de la réussite du développement des Logiciels Libres. Ils permettent tout simplement aux divers développeurs de collaborer en leur facilitant le partage et la mise en commun de contributions.

Aujourd'hui, l'outil le plus répandu est CVS (Concurrent Versions System). On le trouve presque partout, la plupart des plates-formes d'hébergement de projets libres offrent un hébergement de repository CVS (Sourceforge, Savannah pour ne citer qu'eux). Malheureusement, CVS est basé sur RCS (Revision Control System) et hérite de toutes ses erreurs de conception. Trois problèmes majeurs ressortent du lot (la liste pourrait être beaucoup plus longue):
- CVS se base sur le versionning par fichier. Cela interdit les commits dits atomiques ("tout ou rien"). On peut vite se retrouver avec un arbre de sources dans un état incertain pour peu que d'autres développeurs aient crée des situations de conflits.
- CVS ne possède que la notion de fichier... les notions de répertoire, de lien symbolique, de metadata telle que les permissions de fichier lui sont totalement inconnues. Le rennomage d'un fichier est d'ailleurs impossible sous peine de perdre son historique, or, l'intérêt d'un outil de versionning, c'est bien de tracer l'historique des fichiers.
- CVS est un outil profondément centralisé. Le travail des développeurs se fait sur un seul et unique repository de sources dont chacun possède un snapshot de travail. Ce dernier point est celui qui représente le plus grand inconvénient (branches coûteuses et inadaptées, problèmes d'administration... j'en passe et des meilleures).

Ces trois points constituent une bonne part des raisons qui ont poussé Linus Torvalds à se tourner vers un outil propriétaire nommé BitKeeper pour le développement du noyau Linux 2.5. En effet, CVS ne satisfaisait pas le besoin de développement décentralisé du noyau, où chaque hackeur majeur possède sa propre branche et fournit les patchs à Linus pour une admission dans la ligne de développement principale. En 2002, lorsque Linus a cherché un outil libre répondant à ses besoins, le constat était sévère: il n'y en avait simplement pas.

On peut maintenant, après plus d'un an se demander où en sont les choses. Et bien, aussi étonnant que cela puisse paraître, les choses ont peu bougés. Le projet Subversion qui vise à remplacer CVS fait du sur place. Son principal atout est sa ressemblance avec CVS. Mais Subversion n'offre et n'offrira dans un futur proche presque rien de plus que CVS. A dire vrai, des projets comme meta-cvs, se greffant sur CVS, font presque aussi bien que Subversion tout en étant bien moins compliqués.

Moi même intéressé par l'adoption d'un nouvel outil pour mes projets Libres, je suis tombé par hasard sur le projet Arch. A l'époque (Janvier 2003), la seule implémentation d'Arch (programme nommé "larch") était écrite en langage Shell (oui, oui ! à coup de sed, awk et autres programmes shell), bien sûr c'était très (très) lent mais cette implémentation servait surtout à valider les concepts sur lesquels se basait Arch. En voici certains, la liste n'est pas exhaustive:
- Arch se base sur les principes reconnus du "KISS" (Keep It Simple Stupid )
- Arch est orienté patchset. Les commits sont donc atomiques.
- Arch possède les notions de fichier, de lien symbolique, de répertoire et de metadata (permissions d'un fichier). Les rennomages de fichiers/répertoires ne sont plus un problème.
- Les archives Arch peuvent être partagées via les protocoles FTP, SFTP, Plain HTTP et WebDAV.
- Dans Arch, les branches ont un coût constant indépendant du nombre de fichiers du projet.
- Arch est profondément orienté "développement distribué". Rien n'est plus simple que de créer une branche locale de développement pour effectuer ses changements puis de les intégrer ensuite à la branche principale de développement.

Après une longue période d'inactivité de presque un an, son auteur principal, Thomas Lord, s'est mis à coder Arch en C (programme nommé "tla"). Le seul gros inconvénient d'Arch, sa lenteur, n'est plus aujourd'hui qu'un lointain souvenir. Déjà conquis par "larch" en terme de fonctionnalités, "tla" a tout simplement rendu Arch réellement utilisable dans des projets de toute échelle.

Il ne vous reste plus qu'à le tester. Un tutorial assez bien fait vous attends dans les liens afin d'en apprendre les bases et qui sait, peut être de l'apprécier...

Aller plus loin

  • # Re: Arch: un programme de gestion de version prometteur.

    Posté par  (site web personnel) . Évalué à 10.

    Pour mieux gauger :

    Comparaison CVS, Meta-CVS, arch, Subversion, DARCS, OpenCM, monotone, Codeville,

    http://zooko.com/revision_control_quick_ref.html(...)

    ComparaisonSubversion and Meta-CVS :
    http://users.footprints.net/~kaz/mcvs-svn-comparison.html(...)

    Par l'auteur d'arch
    Comparaison arch - bitkeeper :

    http://www.fifthvision.net/open/bin/view/Arch/BitKeeper(...)

    Comparaison arch - subversion :
    http://www.fifthvision.net/open/bin/view/Arch/SubVersionAndCvsCompa(...)

    • [^] # Re: Arch: un programme de gestion de version prometteur.

      Posté par  . Évalué à 2.

      s/gauger/jauger/

    • [^] # Re: Arch: un programme de gestion de version prometteur.

      Posté par  (site web personnel) . Évalué à 1.

      Comparaison arch - bitkeeper

      En résumé, BitKeeper est meilleur, mais les avantages qu'il a sur arch ne sont critiques que sur des projets professionnels (fiabilité des données, vitesse, interface utilisateur, etc.) arch est suffisant pour des développements open source, il gère aussi la fiabilité des données (mais de manière moins poussée que BitKeeper), il est moins rapide (mais s'est nettement accéléré), et n'a pas d'interface graphique (dommage, mais c'est pas la mort).

      Comparaison CVS, Meta-CVS, arch, Subversion, DARCS, OpenCM, monotone, Codeville

      Effectivement, arch a l'air d'être le meilleur d'entre eux (mais l'auteur admet que sa comparaison est biaisée). En tout cas, c'est un des rares à être disponible en version supérieure à 1.0.

      Comparaison arch - subversion

      arch semble être meilleur que subversion. Attention toutefois, encore une fois cette comparaison est biaisée, et comme toutes les comparaisons ci-dessus, elle ne se base que sur la description des capacités des différents systèmes, et non pas sur une expérience pratique !

      Je reste surpris que arch semble meilleur que subversion, qui est en quelque sort le futur remplacement officiel de cvs, avec on imagine tout plein de gros cerveaux derrière (alors que arch semble n'avoir été créé que par une personne).

      • [^] # Re: Arch: un programme de gestion de version prometteur.

        Posté par  (site web personnel) . Évalué à 10.

        Un des développeurs de Subversion se félicite de l'existence des deux projets, attend avec impatience de voir si Arch va vraiment marcher, car il incorpore plein d'idées sympa, et explique que le but de Subversion a toujours été de corriger CVS, et non pas de réinventer la roue (dans le sens positif du terme).

        Par ailleurs, un certain nombre de personnes rappellent que Subversion est compatible avec CVS, au niveau de la syntaxe, mais surtout au niveau des repositories. Pour les gens qui ont un CVS qui tourne depuis des années et dont le repository fait des centaines de méga, c'est capital.

        http://slashdot.org/comments.pl?sid=27540&cid=2958923(...)
        http://slashdot.org/article.pl?sid=02/02/05/2155215(...)

      • [^] # Re: Arch: un programme de gestion de version prometteur.

        Posté par  (site web personnel) . Évalué à 6.

        ne sont critiques que sur des projets professionnels
        arch est suffisant pour des développements open source
        Hem hem.

        • [^] # Re: Arch: un programme de gestion de version prometteur.

          Posté par  (site web personnel) . Évalué à -2.

          > ne sont critiques que sur des projets professionnels
          > arch est suffisant pour des développements open source
          Hem hem.

          Tu pourrais développer un peu ? Je ne comprends pas ce que tu as pu vouloir dire.

          • [^] # Re: Arch: un programme de gestion de version prometteur.

            Posté par  . Évalué à 2.

            on peut interpréter ta phrase par :

            1) un projet open source ne peut pas etre professionnel
            2) un projet open source se contente de peu par rapport à d'autres projets

            hem hem aussi

            • [^] # Re: Arch: un programme de gestion de version prometteur.

              Posté par  (site web personnel) . Évalué à 3.

              1) un projet open source ne peut pas etre professionnel

              On peut l'interpréter comme ça, mais ce n'est clairement pas ce que j'ai voulu dire.

              2) un projet open source se contente de peu par rapport à d'autres projets

              C'est vrai et c'est souvent une source de fierté (mais nous n'avons probablement pas la même idée de ce que signifie se contenter de peu).

          • [^] # Re: Arch: un programme de gestion de version prometteur.

            Posté par  . Évalué à 1.

            peut-être qu'il veut dire tout simplement qu'un projet opensource peut etre professionnel ou du moins géré professionnellement... parce que je ne vois pas non plus pourquoi le developpement opensource devrait etre moins 'professionnel'

          • [^] # Re: Arch: un programme de gestion de version prometteur.

            Posté par  (site web personnel) . Évalué à 2.

            On dirait dans sa phrase que les projets Open Source n'ont pas besoin d'un environnement pro. Pourtant je suis sur que des "projets professionels" utilisent CVS malgré ses limitations.
            Il aurait dit "est suffisant pour la plupart des projets" j'aurais compris. Mais il pourra mieux préciser le fond de sa pensée que moi :)

            • [^] # Re: Arch: un programme de gestion de version prometteur.

              Posté par  (site web personnel) . Évalué à -1.

              J'avais en tête le contraste classique, et toujours valable en immense majorité, entre les gros projets commerciaux, où l'on jette des millions dans tous les aspects du processus, y compris le gestionnaire de versions, et la plupart des projets open source (y compris des gros), où l'on a historiquement toujours fait avec les moyens du bord, en général un peu moins bons sur certains aspects professionnels (fiabilité absolue, vitesse, interface, documentation, etc.), mais amplement suffisants à la tâche, et souvent plus simples et plus évolutifs que le "concurrent" commercial.

            • [^] # Re: Arch: un programme de gestion de version prometteur.

              Posté par  . Évalué à 0.

              Oui, je confirme. Pour le versionning, nous avons un outil commercial propriétaire (quel sombre me*de) et CVS, qui est utilisé depuis nettement plus longtemps et que nous privilégions de fait.
              Nos projets ne sont pas de très grande tailles, et sont plutôt du niveau prototype que produit fini (mais ce n'est pas systématique).
              Dans ce contexte, CVS est tout à fait adapté, y compris dans un contexte professionnel. Je citerais en vrac quelques critères :
              - facilité de mise en oeuvre
              - intégration dans de nombreux environnements (notament avec les divers IDE que nous utilisons)
              - adapté pour des équipes "à taille humaine" (autour de 5 personnes)

              Nous n'avons donc pas besoin d'utiliser un autre produit qui ne nous apporterait rien de plus étant donnés nos besoins. Par contre, ses faiblesses sont parfois des freins, et un outil du "même tonneau" qui les corrige sera certainement bienvenue.

      • [^] # Re: Arch: un programme de gestion de version prometteur.

        Posté par  . Évalué à -1.

        > avec on imagine tout plein de gros cerveaux derrière

        c'est ca le probleme, tu peux en etre sûr !

        C'est tres difficile de faie travailler des gens brillants ensemble. Il faut qu'il y ait un chef qui sache dire non. C'est assez rare.

  • # KISS ???

    Posté par  . Évalué à 3.

    > - Arch se base sur les principes reconnus du "KISS" (Keep It Stupid Simple)

    Cela doit être super bien mais qu'est-ce que c'est ?

    • [^] # Re: KISS ???

      Posté par  (site web personnel) . Évalué à 1.

      Un principe

      • [^] # Re: KISS ???

        Posté par  . Évalué à 9.

        Ca veut aussi dire Keep it simple, stupid !. L'idée est de garder un concept simple et de le pousser à fond pour voir ce qu'il donne, et souvent ça mène à un logiciel fiable, facile d'utilisation (car simple dans sa conception) et qui fait bien son boulot. Ca permet aussi d'éviter l'effet usine à gaz qui frappe certains éditeurs de textes programmés en lisp. (arf!)

        • [^] # Re: KISS ???

          Posté par  . Évalué à 5.

          Ca permet aussi d'éviter l'effet usine à gaz qui frappe certains éditeurs de textes programmés en lisp

          t'as oublié </troll>

          Ben Emacs il fait très bien son boulot, c'est un éditeur de texte, dont le coeur est en C et les bibliothèques pour le support des différents langage et tout et tout est en lisp.

          Maintenant des gens se sont servis de cet interpréteur Lisp pour faire d'autres choses, d'autres briques.

          Et pis de toute façon, un soft aussi paramètrable qu' Emacs où tous ce qui se base sur l'interpréteur Lisp d'Emacs, tu meurts.

          • [^] # Re: KISS ???

            Posté par  . Évalué à -1.

            Ben et Vi????

            oki je ---->[]

          • [^] # Re: KISS ???

            Posté par  . Évalué à 4.

            effectivement, j'ai oublié les balises de troll (c'était pour le faire passer inaperçu).
            <nouvelle tentative>
            Mais cela dit, j'utilise emacs comme tout le monde... (et je suis bien content d'avoir l'adsl pour télécharger les 60Mo qu'occuppe l'éditeur)
            </nouvelle tentative>

          • [^] # Re: KISS ???

            Posté par  . Évalué à 9.

            Emacs : un interpreteur Lisp livré avec quelques exemples.

    • [^] # Re: KISS ???

      Posté par  (site web personnel) . Évalué à 4.

      C'est le principe de base d'Unix, et donc de Linux, qui dit qu'un logiciel, pour être efficace, doit faire une seule chose, mais bien.
      En gros, on évite d'intégrer des tonnes d'outils annexes, et on se concentre sur LA fonctionnalité essentielle.

      • [^] # Re: KISS ???

        Posté par  . Évalué à 1.

        C'est le principe de base d'Unix, et donc de Linux

        ^Linux^GNU

    • [^] # Re: KISS ???

      Posté par  . Évalué à 1.

      le kiss tel qu'il est implementé dans snowwhite.


      -> []

    • [^] # Re: KISS ??? -> à corriger dans le texte de la nouvelle

      Posté par  . Évalué à 4.

      "KISS" Cela doit être super bien mais qu'est-ce que c'est ?

      Il faut dire que l'auteur de la nouvelle s'est planté, c'est : "Keep It Simple, Stupid" soit en traduction litéralle "garde-le simple, idiot". Il s'agit d'éviter d'inventer des trucs compliqués et de garder une certaine simplicité, gage de bon fonctionnement (comme sous Unix en général où on préfère utiliser plusieurs outils simples plutôt qu'un seul compliqué).

  • # Re: Arch: un programme de gestion de version prometteur.

    Posté par  . Évalué à 1.

    Je suis bien intéressé par DARCS personnellement, surtout parce qu'il est fait en Haskell avec une théorie des patchs basée sur la physique quantique derrière :o)

    Quelqu'un y a déjà touché et peut dire ses impressions ?

  • # Re: Arch: un programme de gestion de version prometteur.

    Posté par  . Évalué à 1.

    C'est vrai que le pb de la gestion des branches dans cvs mériterait une évolution.
    L'autre fonctionnalité qui mériterait d'être retouchée est le "check-out reserved", qui gagnerait a être pouvoir utilisé plus facillement, un peu a la clear-case.
    A part ca, CVS c'est vraiment bien !

  • # Re: Arch: un programme de gestion de version prometteur.

    Posté par  . Évalué à 2.

    - Dans Arch, les branches ont un coût constant indépendant du nombre de fichiers du projet.

    Faut-il comprendre que le cout varie en fonctions du nombre de revisions/patches ?

    Dans ce cas c'est mal, non ?

    Sinon ca parait interessant, y'a-t-il deja des projets qui l'utilisent ?

    • [^] # Re: Arch: un programme de gestion de version prometteur.

      Posté par  (site web personnel) . Évalué à 3.

      Faut-il comprendre que le cout varie en fonctions du nombre de revisions/patches ?

      Non, le cout est constant.

      En gros, Arch va juste créer un répertoire pour la nouvelle branche (si besoin est) et la seule chose qui distingue un tag d'une version normale c'est la présence d'un fichier CONTINUATION dans le répertoire du patchset.

  • # Re: Arch: un programme de gestion de version prometteur.

    Posté par  . Évalué à 1.

    J'avais jeté un oeil sur différentes alternatives il y a un an, et Arch m'avait semblé intéressant, mais la documentation auteur semblait assez obscur. Le tutoriel est déjà un grand pas.

    J'avais opté pour Subversion à l'époque ; je ne suis pas tout à fait de l'avis du post considérant subversion comme plus compliqué que CVS, la doc fourni avec étant plutôt très bien faite, même pour un novice.

    Le gros avantage que je vois à Subversion, c'est sa portabilité ; associé à des outils graphiques tels que Tortoise, c'est pas le bonheur, mais presque, pour tous les développeurs.

    Quelqu'un sait-il si il y a un port win32 de prévu pour Arch, d'une façon ou d'une autre ? (dans un package complet, pas via cygwin).

    • [^] # Re: Arch: un programme de gestion de version prometteur.

      Posté par  . Évalué à 4.

      Le gros défaut de subversion pour moi c'est d'avoir besoin d'une usine à gaz pour fonctionner (apache2, webdav, ....).

      Alors que CVS, tu installes le binaire, et il fait tout comme un grand.

      • [^] # Re: Arch: un programme de gestion de version prometteur.

        Posté par  (site web personnel, Mastodon) . Évalué à 1.

        Et pi, ça marche sous Windows et avec wincvs, les Windows users peuvent jouer au cliquodrôme en faisant de la gestion de conf libre.

      • [^] # Re: Arch: un programme de gestion de version prometteur.

        Posté par  . Évalué à 2.

        Mouais ; faut tout de même distinguer l'aspect serveur (pour CVS, comme pour Subversion) de l'aspect client.

        Pour Subversion et CVS, l'installation client est équivalente. L'usage, à chacun de voir.

        Pour l'installation serveur, si on veut utiliser Apache/Webdav avec Subversion, c'est _un peu_ galère, mais pas infaisable ; il existe également un serveur Subversion simple (svnserver) accessible via ssh comme n'importe quel serveur CVS.

        En outre, l'installation serveur, dans ce genre de système, c'est une tâche qui est relativement rare (il y a moins de serveurs que de clients).

        Bon, de toutes façons, je crois que c'est encore une histoire de goûts et de couleurs... :-)

        • [^] # Re: Arch: un programme de gestion de version prometteur.

          Posté par  (site web personnel) . Évalué à 2.

          Version serveur simple pour laquelle il est precise sur le site qu'elle n'est pas maintenue et pas developpee parce que les developpeurs ont d'autres priorites en ce moment.

          Perso, j'ai pas trop envie d'installer Apache + webdav et j'aime bien l'installation minimaliste de CVS. Dommage.

    • [^] # Re: Arch: un programme de gestion de version prometteur.

      Posté par  (site web personnel) . Évalué à 4.

      Sinon, je suis tombé sur ça [http://aegis.sourceforge.net/(...)]. D'après l'auteur, il est vachement bien (évidemment :-)) et il semble avoir des fonctionnalités intéressantes (comme le support des /changesets/, à la BitKeeper). Maintenant, ma question est : quelqu'un a-t-il eu des retours dessus ? C'est toujours casse-bombons de réapprendre un nouveau soft juste pour s'apercevoir qu'il ne fait pas l'affaire. Du coup, si quelqu'un avait testé, j'aimerais bien savoir ce qu'il en a pensé...

      Envoyé depuis mon PDP 11/70

      • [^] # Re: Arch: un programme de gestion de version prometteur.

        Posté par  . Évalué à 3.

        Aegis est plus qu'un simple gestionnaire de version, il gere aussi la maniere de developper. C'est a la fois un avantage et une faiblesse suivant que la methode qu'il preconise te convient ou pas. Ce qui est vraiment sympa (surtout pour les gros projets) c'est la gestion des roles et le testing/review du code obligatoire. Le probleme principal que j'avais trouve etait qu'il n'y avait pas de version windows et le manque de client graphiques (idem pour arch qui est le VCS qui me tente le plus en ce moment).

  • # À votre bon coeur

    Posté par  (site web personnel) . Évalué à 10.

    Ça fait un petit choc de lire le tutoriel, d'être dans un bon trip technique, et de se voir soudain rappeler à une réalité plus sombre. L'auteur d'arch est au chomage depuis plus d'un an, il a épuisé toutes ses réserves d'argent et il est surendetté.

    http://regexps.srparish.net/tutorial-tla/little-help.html(...)

    • [^] # Re: À votre bon coeur

      Posté par  . Évalué à 2.

      c'est vraiment dommage vu la qualité du soft.
      amha Arch pourrait vraiment décoller si on en parlait un peu plus (qui connaissait arch avant cette news?)

    • [^] # Re: À votre bon coeur

      Posté par  . Évalué à 2.

      Effectivement ca fait mal au coeur. C'est pas le premier exemple ceci dit. Il y a un developpeur d'Abiword (au moins) au chomage, qui fait du bon boulot et c'est tres injuste egalement.

      Ceci dit il y a le lien vers PayPal...

      • [^] # Re: À votre bon coeur

        Posté par  (site web personnel) . Évalué à 4.

        C'est pas le premier exemple ceci dit. Il y a un developpeur d'Abiword (...)

        Il y a aussi Bram Moolenaar, l'auteur de Vim et d'A-A-P, je crois. Il consacre presque tout son temps aux logiciels libres, et se débrouille mystérieusement pour survivre. (Le projet A-A-P est financé par une association à but non lucratif et est en quelque sorte un emploi pour lui. En contrepartie il a des gens à convaincre, et des objectifs à tenir.)

    • [^] # Re: À votre bon coeur

      Posté par  . Évalué à -1.

      C'est tres malheureux , mais je trouve que se retouver dans cette situation est stupide.
      Si au moins il s'etait endetté pendant un an pour faire quelque chose de vendable, ou a la rigueur de tres demandé sur le marché ( java, cluster, .Net,...) , je comprendrait. Mais là ... passer son temps sur du C et des scripts, le tout sous GPL alors qu'on ne gagne pas de quoi payer le loyer et remplir le gardemanger...

      Je vois ca d'ici : coder c'est tellement agreable ...!


      mouais bon -> []

      • [^] # Re: À votre bon coeur

        Posté par  (site web personnel) . Évalué à 6.

        Il y a surtout une part de naïveté, notamment quand il dit arch can (with a little more development) save the industry millions in licensing fees for proprietary revision control systems. IBM, Red Hat, HP/C, United Linux members, Apple, potential business partners with capital: I'm talking to you! Send me email. Il s'imagine que ces sociétés vont tomber sur son bout de page et bondir à son secours ? Il pourrait peut-être se faire financer par une de ces entreprises, mais ça ne viendra qu'après qu'il les ait activement (et longuement, probablement) baratiné (au sens positif du terme).

        Par ailleurs, il se refuse à suivre l'évolution du marché du travail : il ne cherche que des jobs de programmation C/Scheme/sh/awk, et affirme n'avoir jamais touché à PHP, SQL, Java, etc. Il doit encore exister de tels jobs, mais dans une région où le chomage frappe durement, ce n'est pas en restant chez soi à coder arch que l'on a une chance de les décrocher.

        Bref, ce gars là a toute ma sympathie, c'est un bon codeur et il a contribué significativement à la cause, mais je ne peux m'empêcher de me dire qu'il faut aussi savoir gérer sa propre vie, et que s'il va droit dans le mur, c'est en bonne partie de sa faute. L'informatique évolue, il faut évoluer avec elle.

      • [^] # Re: À votre bon coeur

        Posté par  . Évalué à -2.

        quelque chose de vendable/b>, ou a la rigueur de tres demandé sur le marché ( java, cluster, .Net,...)

        joli troll :o)

        --> []

    • [^] # Re: À votre bon coeur

      Posté par  . Évalué à 5.

      C'est marrant, je suis exactement dans la meme situation avec le développement de Prelude. Malheureusement, il faut croire que personne n'est disposé à aider... Pas meme les sociétés qui font de l'argent sur le projet.

      http://listes.tuxfamily.org/?A=READ&L=prelude-devel_prelude-ids(...)

  • # Cette news c'est une merde !

    Posté par  . Évalué à -2.

    > Le projet Subversion qui vise à remplacer CVS fait du sur place.

    N'importe quoi.
    Regardes ici :
    http://subversion.tigris.org/servlets/SummarizeList?listName=svn(...)

    Cette mailing stocke les commits de subversion. globalement le rythme n'a pas changé.

    Subversion est en phase beta. C'est pas la bonne période pour faire des inovations. De plus Subversion est de plus en plus utilisé et ce n'est pas non plus de moment de tout casser. L'objectif c'est la version 1.0 puis les inovations seront de retour.

    NON et NON et NON subversion ne fait pas du sur place.

    > Mais Subversion n'offre et n'offrira dans un futur proche presque rien de plus que CVS.

    Excuse moi mon cher Edouard Gomez, mais tu es un con. Si tu t'étais renseigné 2 secondes tu aurais vu que ce que tu apprécies sur arch, existe sur subversion :
    - les commits sont atomiques. C'est du versionnage de branche et non uniquement de fichier
    - subversion ne se limite pas au fichier, il reconnait aussi les repertoire, tu peux les renommers, etc... Par contre la gestion des liens symboliques sera pour après version 1.0.
    - Dans subversion il y a aussi la copie à coût 0 (la création d'une branche étant une copie).
    - Lorsque tu développes avec subversion, tu as un dépôt local où tu fais toutes tes opérations. Après du peut faire un commit vers le serveur.
    - Subversion, le backend, est orienté base de données. Actuellement il utilise Berkeley DB mais après la version 1.0 d'autre base de donnée seront supporté (mysql/postgresql, etc).
    - Subversion consomme peut de réseau. Seul les diffs circulent et en compressé.
    - Subversion dispose déjà de client graphique qui tourne sous Unix et Windows.
    - Subversion est très portable et basé sur la lib apr d'apache. Ainsi, Subversion tourne déjà pratiquement partout (Linux, Unix, Windows, Mac).
    - Le protocol réseau de Subversion est parfaitement standard puisque c'est webDav. Tout client Dav peut fouiller un dépôt Subversion. Pour le serveur, Apache est utilisé (+ module dav + module subversion). C'est une garanti d'efficacité et de sécurité. C'est donc très facilement qu'https est dispo.
    - etc

    C'est "presque rien de plus que CVS" ? Subversion veut remplacer CVS mais au près des utilisateurs ! Ça ne veut pas dire que Subversion va recoder CVS ! Faut être con pour croire ça.

    > A dire vrai, des projets comme meta-cvs, se greffant sur CVS, font presque aussi bien que Subversion tout en étant bien moins compliqués.

    100 % pure troll.

    Le point fort de arch par rapport à subversion est son modèle plus distribué. Subversion restant sur un modèle plus centralisé. Cependant, l'objectif premier de subversion est TOUS les developpeurs et non seulement les développeurs de Linux. Quoiqu'il en soit, les devs de Linux ne sont pas oubliés. Un nouveau format de patch existe et permet de s'échanger des patchs qui contient des infos sur le renommage de fichier, déplacement des répertoires, changement d'attribut (les meta-donné) etc... Donc il n'y a pas de problème, a moyen terme ,pour la version 1.2 ou 2.0, les developpements distribués ne sont pas oubliés. Les fonctionnalités 1.0 sont déjà suffisante pour la faire (faire un "appliqué les différence entre la version 100 et 242 du dépôt d'Alan Cox sur mon dépôt local (avec renommage, meta-data, etc)" par exemple).

    C'est news c'est de la MERDE.

    PS : NRV.

    • [^] # Re: Cette news c'est une merde !

      Posté par  . Évalué à -2.

      J'oubliais : j'ai rien contre arch.

    • [^] # Re: Cette news c'est une merde !

      Posté par  . Évalué à 5.

      > Excuse moi mon cher Edouard Gomez, mais tu es un con.

      > C'est news c'est de la MERDE.

      T'as un problème familial ? Des soucis dans ta vie de couple ? Non ? Alors c'est quoi ton excuse ?

      Depuis quand ne pas être d'accord avec quelqu'un ou avoir des corrections à apporter sur un sujet autorise à être incorrect, malpoli, grossier, tout ça en une seule fois ?

      Dommage, ton post semblait intéressant en dehors de ça.

      HS -> Merci de moinsser.

      • [^] # Re: Cette news c'est une merde !

        Posté par  . Évalué à -8.

        > T'as un problème familial ? Des soucis dans ta vie de couple ?

        Je bande mou.

        > Depuis quand ne pas être d'accord avec quelqu'un

        Qu'Edouard Gomez ne connaisse pas Subversion n'est pas critiquable. Qu'il n'aime pas Subversion non plus. Par contre attaquer subversion comme il le fait (avancer des allégations fausses etc...) et une démarche clairement volontaire de nuire. C'est ça qui m'énerve. C'est la démarche volontaire de nuire au projet Subversion.

        > autorise à être incorrect, malpoli, grossier, tout ça en une seule fois ?

        Non. Je l'ai fais sans autorisation.

    • [^] # Re: Cette news c'est une merde !

      Posté par  (site web personnel) . Évalué à 9.

      > NON et NON et NON subversion ne fait pas du sur place.

      Si tu crois que j'ai dis que Subversion etait moribond, c'est complètement faux, le développement de Subversion va bon train. Mais en terme de fonctionnalités, je suis désolé mais Subversion évolue TRES (trop?) lentement. Trop de choses sont reportées pour l'après 1.0.

      > Excuse moi mon cher Edouard Gomez, mais tu es un con.

      Ce jugement gratuit montre que je parle à un connaisseur en la matière.

      >Si tu t'étais renseigné 2 secondes tu aurais vu que ce que tu apprécies sur arch, existe sur subversion :
      >[liste de features...]

      Je n'ai jamais affirmé que Subversion ne répond pas à certains problèmes de CVS, et cette liste de features est accessible sur le site de tigris, dont j'ai posté le lien pour que les lecteurs puissent aller chercher des informations complémentaires, y compris sur Subversion, le projet que je tente de diaboliser d'après tes dires... ah mais oui ! je ne suis qu'un con, c'est vrai, j'oubliais.

      Maintenant, regardons plus en détail cette liste de features:
      >commits atomiques

      oui rien a redire, c'est présent depuis que je connais Subversion

      >Subversion, le backend, est orienté base de données. Actuellement il utilise Berkeley DB mais après la version 1.0 d'autre base de donnée seront supporté (mysql/postgresql, etc).

      Sur ce point, je dirais que sur le papier, ce point a l'air très intéressant, mais lorsque j'ai testé Subversion sur l'import d'un noyau Linux 2.4.19 en Octobre 2002, le backend BerkeleyDB massacrait les perfs de Subversion... l'import en _local_ sur un p4 1.5GHz et 512MB de RAM avait mis 40minutes... le premier checkout 20Minutes. Les commits eux étaient raisonnables et tournaient autour de 2/3 minutes le temps de traverser l'arbre complet des fichiers (qui est conséquent). Ce qui semble etre un avantage, ne l'est peut etre pas dans tous les cas. J'espère que Subversion a progressé dans ce domaine.

      >Subversion consomme peut de réseau. Seul les diffs circulent et en compressé.

      Cette innovation est bien mince mais certes bon point pour Subversion.

      >Subversion dispose déjà de client graphique qui tourne sous Unix et Windows.

      Oui en effet, tu fais bien de le signaler. Subversion possède plus d'outils périphériques. Pourquoi ? Car ca fait déjà quelques temps qu'on nous le présente comme LE successeur de CVS. Il attire donc plus l'attention des développeurs que Darcs ou Arch. Il est alors tout a fait compréhensible qu'on trouve ces outils plus user friendly...

      >Subversion dispose déjà de client graphique qui tourne sous Unix et Windows.

      Sur ce point je n'ai rien a redire, c'est une vrai force de Subversion.

      >Le protocol réseau de Subversion est parfaitement standard puisque c'est webDav. Tout client Dav peut fouiller un dépôt Subversion. Pour le serveur, Apache est utilisé (+ module dav + module subversion). C'est une garanti d'efficacité et de sécurité. C'est donc très facilement qu'https est dispo..

      Oui, tout à fait vrai, Subversion a su exploiter ce que WebDAV offre de base (opérations classiques sur fichier + versionning). Maintenant il faut aussi avouer que ce choix du "tout WebDAV" a énormément complexifié le backend. L'implémentation dav de subversion est loin, très loin d'être triviale.

      >C'est "presque rien de plus que CVS" ? Subversion veut remplacer CVS mais au près des utilisateurs ! Ça ne veut pas dire que Subversion va recoder CVS ! Faut être con pour croire ça.

      Je n'ai jamais avancé de tels propos. Inventes ce que bon te plais. j'ai juste dis que "Subversion se positionne comme LE successeur de CVS".

      >> A dire vrai, des projets comme meta-cvs, se greffant sur CVS, font presque aussi bien que Subversion tout en étant bien moins compliqués.
      >100 % pure troll.

      1/ le terme "compliqué" se réfère à l'implémentation, non à l'outil vu par l'utilisateur.
      2/ Relis la page de tigris, les features vraiment novatrices sont pour "l'après 1.0" qu'on attend si patiemment. Et toi même tu l'avoues.

      >C'est news c'est de la MERDE.

      D'abord on dit "_cette_ news c'est de la MERDE". Puis ensuite je remarque juste que ton commentaire n'est pas constructif... bref tu ne réhausses pas le niveau si pitoyable de ma news.

      >PS : NRV.

      T'es pas beau quand tu t'ennerves, reste calme, c'est juste un conseil de la part du "con".

      • [^] # Re: Cette news c'est une merde !

        Posté par  . Évalué à 1.

        > >C'est "presque rien de plus que CVS" ? Subversion veut remplacer CVS mais au près des utilisateurs ! Ça ne veut pas dire que Subversion va recoder CVS ! Faut être con pour croire ça.

        > Je n'ai jamais avancé de tels propos. Inventes ce que bon te plais. j'ai juste dis que "Subversion se positionne comme LE successeur de CVS".

        La phrase exacte est :
        - "Mais Subversion n'offre et n'offrira dans un futur proche presque rien de plus que CVS."

        Lis ton article s'il te plait.

        > 2/ Relis la page de tigris, les features vraiment novatrices sont pour "l'après 1.0" qu'on attend si patiemment. Et toi même tu l'avoues.

        les "features vraiment novatrices" par rapport à CVS sont avant la version 1.0 (atomicité, gestion des répertoires, versionning de branche, coût 0 des copies, meta-donnée). Tu confirmes j'espère ?

        • [^] # Re: Cette news c'est une merde !

          Posté par  (site web personnel) . Évalué à 0.

          >les "features vraiment novatrices" par rapport à CVS sont avant la version 1.0 (atomicité, gestion des répertoires, versionning de branche, coût 0 des copies, meta-donnée). Tu confirmes j'espère ?

          Non, pour moi ces features sont en grande partie que des corrections des erreurs de CVS. C'est pourquoi pour moi, les features que j'attend sont pour l'apres 1.0.

          Ceci dit je le répète je ne crache pas sur Subversion mais Darcs et Arch me semblent bien plus prometteurs que Subversion.

          • [^] # Re: Cette news c'est une merde !

            Posté par  . Évalué à 2.

            Tu es quand même marrant toi. 95 % des fonctionnalité de Arch sont dans Subversion. Il y a 5 % plus dans Arch par rapport à Subversion et 5 % dans Subversion par rapport à Arch et je suis très généreux. Le tar.gz de svn fait dans les 9 Mo et Arch 2,8. De plus Subversion s'appuis sur d'autres composants comme libapr, neon, db4, webdav et les 9 Mo c'est sans les interfaces graphiques. Et en fouillant rapidement je doit très, très, très facilement trouver des fonctionnalités/caractéristiques dans Subversion qui ne sont pas dans Arch.

            Conclusion pour toi : Subversion n'est qu'une copie de CVS et d'un classicime rébarbatif alors que Arch est révolutionnaire. Faut pas pousser.

            • [^] # Re: Cette news c'est une merde !

              Posté par  (site web personnel) . Évalué à 3.

              Arch et Subversion ont deux buts différents. Subversion cherche à remplacer CVS, et vise à corriger les problèmes majeurs de CVS pour sa version 1.0, et à ajouter de nouvelles fonctionnalités dans les versions ultérieures. Me trompé-je beaucoup en pensant que Subversion se concentre sur la réalisation d'une implémentation en béton armé, portable, en quelque sorte, ultime ? Arch de son côté cherche à innover. Il ne s'embarrasse pas de compatibilité CVS, il court en avant dans des territoires inexplorés (au moins en open source). Il y a également (une conséquence de son statut) beaucoup moins de gens derrière Arch que derrière Subversion. Il n'est donc pas étonnant qu'Arch ne fournisse que le coeur du système (mais un coeur qui a l'air bien solide), et que son code source soit beaucoup plus léger que celui du poids-lourd Subversion.

              Conclusion pour toi [Édouard]: Subversion n'est qu'une copie de CVS et d'un classicime rébarbatif alors que Arch est révolutionnaire. Faut pas pousser.

              Je n'irais pas jusqu'à dire ça, mais les deux projets ne sont pas équivalents, et ont peut difficilement les comparer à coups de pourcentage de fonctionnalités. Tout comme l'auteur de Subversion dont j'ai parlé plus haut, je suis intéressé par l'évolution des deux systèmes. Dit d'une autre manière : j'aurais a priori plus confiance en Subversion pour l'hébergement d'un projet critique, mais j'ai bien envie d'essayer arch parce qu'il a l'air plus cool, et pas immature pour autant.

              Et en fouillant rapidement je doit très, très, très facilement trouver des fonctionnalités/caractéristiques dans Subversion qui ne sont pas dans Arch.

              Chiche !

              • [^] # Re: Cette news c'est une merde !

                Posté par  . Évalué à 1.

                Voilà un discours conhérent.

                > Subversion cherche à remplacer CVS

                C'est vrai. Mais il faut "éclairer" ce point. Subversion ne veut pas remplacer CVS par un équivant à 100 % (je sais t'aime pas les pourcentage). C'est remplacer CVS dans la communauté du logiciel libre. CVS est très utilisé et est pratiquement seul dans le LL (ça change petit à petit avec le déploiement de subversion : http://svn.debian.org/(...) ). CVS est veillissant et il faut le remplacer. Remplacer CVS par un équivalent de CVS n'a aucun sens. Il faut faire mieux. Après il ne faut pas oublier les habitudes de la "communauté" et introduire des incompatibilités gratuite à CVS ou ne pas permettre l'importation d'arbre CVS vers Subversion est une erreur. C'est volonté de remplacer CVS n'empêche pas l'inovation et Subversion le prouve.

                Je suis parfaitement d'accord avec toi. Subversion et Arch, se nourrissent l'un de l'autre. Par exemple Tom Lord est (ou était) fréquament sur la mailing list de Subversion.

                > Chiche !

                Heu, non. Là je suis à la bourre. Mais rapidement il y a les hooks côté serveurs (pour authentification par répertoire, et plein d'autre goodies), l'abstraction de stockage (utilisation futur de SQL), la copie de référence dans le dépôt local, les backup à chaud (c'est actuellement un fonctionnalité db4 mais c'est aussi de fait dans postgresql). C'est des exemples et comme je connais pas parfaitement Arch ...

        • [^] # Re: Cette news c'est une merde !

          Posté par  (site web personnel) . Évalué à 3.

          OK, OK, d'accord, le thread est devenu chiant et un nids à nervosité et un échange d'insultes... la news n'était effectivement pas rédigée au mieux, mais le commentaire d'origine de ce thread était un peu trop énervé, imaginez la suite...

          Quand une version RC de Subversion arrivera dans les bacs, tu nous postes une news aussi complète ptit_tux ? (sasn tomber dans le troll ? ;-)

          Merci en tout de compléter la news de vos corrections.

      • [^] # Re: Cette news c'est une merde !

        Posté par  (site web personnel) . Évalué à 2.

        >>Subversion dispose déjà de client graphique qui tourne sous Unix et >>Windows.

        >Oui en effet, tu fais bien de le signaler. Subversion possède plus d'outils >périphériques. Pourquoi ? Car ca fait déjà quelques temps qu'on nous le >présente comme LE successeur de CVS. Il attire donc plus l'attention des >développeurs que Darcs ou Arch. Il est alors tout a fait compréhensible qu'on >trouve ces outils plus user friendly...

        Un bon outil graphique pour CVS: lincvs ( http://www.lincvs.org(...) ).
        En tout cas, pour l'utilisation que j'en ai, il répond à mes besoins :-)

        --
        http://titux.tuxfamily.org(...)

        • [^] # Re: Cette news c'est une merde !

          Posté par  (site web personnel) . Évalué à 1.

          Et quand on est coincé dans un monde de fenêtres propriétaires, il y a moyen d'entrouvir une lucarne et de respirer un peu d'air frais : http://www.tortoisecvs.org/(...)

          • [^] # Re: Cette news c'est une merde !

            Posté par  (site web personnel) . Évalué à 3.

            Tu aurais répondu WinCVS, j'aurais été d'accord, mais TortoiseCVS me plait moins, surtout parce qu'il se mélange à l'explorateur de fichiers de Windows. Et à part le côté gadget de la chose, je préfère séparer nettement les deux fonctions.

            • [^] # Re: Cette news c'est une merde !

              Posté par  (site web personnel) . Évalué à 1.

              Honnêtement, j'ai essayé WinCVS, j'ai trouvé que c'était un GUI pourri de bugs et pas pratique du tout à utiliser. J'ai donc laissé tomber l'usine à gaz, j'ai fait un peu de CVS en ligne de commande, et puis j'ai découvert TortoiseCVS.

              C'est justement l'intégration avec l'explorateur qui fait toute sa force : tu te balades dans ton arborescence, tu as des fichiers avec un petit check vert (committés, tout va bien), des petites croix rouges (modifiés localement, faudrait penser à committer) ou des petits points d'interrogation bleus (pas enregistrés dans le repository). Tout est simple d'utilisation : quelques petits coups de clic droit pour ajouter un fichier, pareil pour committer un fichier ou un bout d'arborescence. Les checkout se font tout aussi simplement, avec un clic-droit sur un répertoire.

              Ça peut te sembler gadget, mais pour moi c'est génial. Simple, agréable, sans jamais de prise de tête, on en vient à faire des checkout et des checkin à tout bout de champ (euh, avec modération bien sûr, hips).

              Ceci dit, ça fait six mois que je n'ai pas touché à TortoiseCVS (ou à Windows, d'ailleurs), et plus d'un an que j'ai testé WinCVS, donc les choses ont peut-être évolué. Mais même si WinCVS est devenu utilisable, TortoiseCVS restera mon interface préférée.

              • [^] # Re: Cette news c'est une merde !

                Posté par  (site web personnel) . Évalué à 1.

                Avantage de l'appli séparée: tu as plein de raccourcis clavier (graphique des versions ? ctrl-g).
                Moi je crois que je vais avoir tendance à utiliser les deux.

              • [^] # Re: Cette news c'est une merde !

                Posté par  (site web personnel) . Évalué à 3.

                Je souscrit a 200% a cet avis. WinCVS n'est qu'une excuse pour dire que CVS a un client graphique sous windows, mais ce client ne simplifie en rien l'utilisation de CVS, plutot le contraire. L'interface en ligne de commande de CVS est bien plus simple a utiliser. Tortoise au contraire, est simple et intuitif. Tu regardes tes repertoires, tu vois tout de suite les fichiers qui ont besoin de ton attention (marques en rouge). Quand tu fais un click-droit dessus, il te propose uniquement les actions qui sont intelligentes par rapport a l'etat du fichier, ce qui donne une impression de facilite incroyable. Tu cliques sur un fichier modifie, il te propose soit un diff, soit de le committe. Sur un fichier non encore dans la base, il te propose de l'ajouter ou de l'ignorer. Je regrette que le monde linux n'est pas un aussi bon client CVS mais j'envisage un jour de modifier Cervisia pour obtenir ce genre de fonctionnalite.

                • [^] # WinCVS c'est pratique

                  Posté par  . Évalué à 1.

                  WinCVS n'est qu'une excuse pour dire que CVS a un client graphique sous windows, mais ce client ne simplifie en rien l'utilisation de CVS, plutot le contraire. L'interface en ligne de commande de CVS est bien plus simple a utiliser. Tortoise au contraire, est simple et intuitif. Tu regardes tes repertoires, tu vois tout de suite les fichiers qui ont besoin de ton attention (marques en rouge). Je suis étonné de te lire. WinCVS compliquerait l'utilisation de CVS ?? J'utilise WinCVS depuis longtemps (actuellement la version 1.2, il en existe de plus récentes) et le fonctionnement est à peu près le même que celui que tu indiques concernant Tortoise (que je ne connais pas). Sous WinCVS aussi on a immédiatement la vue des fichiers modifiés en rouge, des fichiers non encore sous CVS, etc... Je n'ai pas l'impression que Tortoise apporte grand chose en plus. Par ailleurs, je ne trouve pas que CVS soit simple à utiliser en ligne de commande, sans outil graphique (WinCVS/LinCVS) je suis beaucoup moins à l'aise, essentiellement pour avoir rapidement la vue de ce qui a changé ou pas. De plus, j'utilise un "diff externe" avec WinCVS donc le mode graphique m'arrange.

                  • [^] # Re: WinCVS c'est pratique

                    Posté par  . Évalué à 2.

                    je ne trouve pas que CVS soit simple à utiliser en ligne de commande, pas simple ? cvs co mon_module cvs add mon_fichier cvs diff [mon_fichier] cvs ci [mon_fichier] cvs update quoi d'autre ??? (pour le commun des mortels) Pour moi, tant que ca se compte sur les doigts de la main, c'est du domaine de l'hyper simple. Et pour avoir des zolies couleurs: http://www.freekde.org/neil/colorcvs/

                • [^] # Re: Cette news c'est une merde !

                  Posté par  . Évalué à 2.

                  J'abonde dans ce sens. Turtoise est une manière naturelle d'intégrer CVS dans le système, peut-être de la même manière que la version ligne de commande est naturelle dans une CLI unix.

                  J'ajouterais que ça donne une excellente vue d'ensemble (avec les couleurs et la présentation hiérarchique) et qu'il existe un équivalent portable et peut-être meilleur, d'ailleurs : un mode cvs standard pour emacs (M-x cvs-status).

    • [^] # Re: Cette news c'est une merde !

      Posté par  (site web personnel) . Évalué à 2.

      Je suis tout à fait d'accord avec pour tes arguments, et je crois bcp plus en Subversion qu'en n'importe quel autre système de gestion de version.
      Pour autant, ce n'est pas une raison d'utiliser un tel ton. Fait de la boxe ou crie un bon coup dans ta piaule, mais n'utilise pas LinuxFR pour passer tes nerfs !

      L'auteur de la news n'est pas un con. Il aime arch et il n'est pas forcément objectif. Et alors ? C'est pas la peine de lui parler comme ça.

      • [^] # Côté positif du thread

        Posté par  (site web personnel) . Évalué à 2.

        Il faut voir le côté positif de ce thread. Ca nous change quand même des thèmes d'étripage classique:

        - Sur vi et emacs,
        - Sur les distributions Linux,
        - Sur XFree et le framebuffer.

        :-)

        Finalement, c'est presque rafraichissant, non ? ;-)

        Mickaël

    • [^] # Re: Cette news c'est une merde !

      Posté par  . Évalué à 3.

      Le gus qui vote [-] à mon post, devrait lire attentivement mon post et la doc de subversion avant !

      C'est ici :
      http://svnbook.red-bean.com/html-chunk/(...)

      Pour une présentation c'est ici :
      http://subversion.tigris.org/files/documents/15/702/Subversion-Blai(...)

      Le reste de la doc est ici :
      http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=(...)

      Regarder à Design, Book, HowTo, Presentations.

      Si vous votez [-] à cause des insultes, j'ai rien contre.

      • [^] # Re: Cette news c'est une merde !

        Posté par  . Évalué à 3.

        Si j'ai voté [-] à ton post, c'est parce qu'il est agressif et insultant sans raison.

        • [^] # Re: Cette news c'est une merde !

          Posté par  . Évalué à 0.

          Sans raison je ne suis pas d'accord (relis).
          Si c'est car il est "agressif et insultant" je t'en veux pas.

        • [^] # Re: Cette news c'est une merde !

          Posté par  . Évalué à 4.

          pareil,
          je trouve ce comportement totalement immature. Une news est quasi obligatoirement partiale, une personne faisant la demarche pour soumettre une nouvelle la privilégiant deja par rapport a une autre. Les journalistes eux memes sont rarement objectifs, et c'est souvent la raison qui motive l'achat d'un journal. Bref je digresse, mais il n'empeche qu'une personne qui poste une nouvelle clairement sans volonté de nuire a quiconque n'a pas a se faire traiter de cette facon. Cela n'encourage personne à soumettre des articles si on s'expose a ce genre de comportement agressifs. La moidre des corrections serait de t'excuser.
          Vas y c'est la, je le merite le [-], ca te soulagera peut etre ;-)

          • [^] # Re: Cette news c'est une merde !

            Posté par  . Évalué à -2.

            > Vas y c'est la, je le merite le [-], ca te soulagera peut etre ;-)

            Premièrement, je ne vote jamais à un post où je fais une réponse. Si je répond, utiliser en plus les votes, c'est abuser. De plus je n'ai pas de vote actuellement...

            > La moidre des corrections serait de t'excuser.

            Non. Il a clairement et volontairement mit des phrases pour dénigrer Subversion :
            - "Le projet Subversion qui vise à remplacer CVS fait du sur place."
            - "Mais Subversion n'offre et n'offrira dans un futur proche presque rien de plus que CVS."
            - "A dire vrai, des projets comme meta-cvs, se greffant sur CVS, font presque aussi bien que Subversion tout en étant bien moins compliqués."

            Si tu connais Subversion tu ne peux que conclure que c'est des conneries.

      • [^] # Re: Cette news c'est une merde !

        Posté par  (site web personnel) . Évalué à 1.

        J'ai pas voté négatif car j'aime pas "moinsser". Par contre, je comprends les personnes qui ont votées [-] car les insultes suffisent à expliquer leurs votes. Par ailleur, l'aspect technique de votre discussion etait très interressant.

  • # Première impression

    Posté par  . Évalué à 3.

    Je viens d'imprimer la documentation et d'achever la compilation. Dans mon cas je ne connais CVS que de nom, Subversion la même chose.

    Je suis un ignorant dans les systèmes de gestions de versions. C'est donc en ignorant que je donne mes premières impressions sur Arch, ... franchement c'est sympas. Le tutorial est pas mal fait.

    Donc pour ceux qui ont en horreur l'installation des usines à gaz qui donnent mal à la tête rien que d'y penser, l'installation et la prise en main de arch est vraiment accessible.

    Il ne me reste plus qu'à essayer Subversion, car vue les controverses qu'il génère ici il doit être bien sympathique.

    Par contre est-ce que quelqu'un à déjà mis en place ce genre de système dans de petites structures de développement d'intranet de gestion ?

    Je travaille dans une structure où les développeurs sont minoritaires et les graphistes majoritaires.

    Vous avez une idée pour mettre en place une procédure de production qui utiliserai Subversion ou Arch accessible à des graphistes ?

    zax

    • [^] # Re: Première impression

      Posté par  . Évalué à 4.

      Installer subversion sans la partie serveur est facile. Tu peux créer un dépôt local (svnadmin create file://path/ ).

      Je te conseille vivement de lire la doc de subversion (excellente même si elle est un peu longue pour un débutant).

      Pour l'installation, il y a des paquets :
      http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=(...)

      rh 9 est livré avec subversion 0.17 . Mais il n'y a pas la partie serveur (tu peut toujours créer un dépôt local). Ça permet de mettre le pied à l'étrier.

      > les graphistes majoritaires.

      Regardes de ce côté là. Ça tourne aussi sous Windows :
      http://rapidsvn.tigris.org/(...)

      Si c'est pour de la production, veilles à faire des dumps (svnadmin dump). C'est le dump est fait référence pour les montées de version (c'est comme postgresql).

      • [^] # question précise ... réponse précise

        Posté par  . Évalué à 1.

        Merci pour les infos, elles me seront d'une aide précieuse. Je sens que grâce à tout ses outils que nous fournissent nos développeurs libre, je vais enfin pouvoir mettre en place des structures de productions solides sans briser les reins de mon gentil patron sur le plan financier.


        En regardant très rapidement les sites que tu m'as passé il apparait que Subversion sera plus facile à faire accepter vu que une partie est sous linux l'autre sous windows, donc je vais continuer à creuser tout cela.


        En tout cas merci pour la rapidité et la précision de ta réponse.


        Zax

        • [^] # Re: question précise ... réponse précise

          Posté par  . Évalué à 2.

          > vu que une partie est sous linux l'autre sous windows

          Non. Tout peut tourner sous Windows et Unix. Subversion utilise libapr d'apache qui est utilisé pour la portabilité d'apache. Donc partout où tourne apache, subversion peut tourner. Par contre, c'est n'est pas le cas des outils graphiques. Actuellement il n'y a que RapidSvn qui tourne sous Windows et Unix.

  • # Mmm, du bon tarball tout frais

    Posté par  (site web personnel) . Évalué à 1.

    Marrant, tla (l'implémentation en C de Arch) est sorti en version 1.0.6 ajourd'hui. :)

  • # Re: Arch: un programme de gestion de version prometteur.

    Posté par  . Évalué à 2.

    Personne n'a parle de ClearCase ici, qui est je pense un des meilleurs logiciels de gestion de versions (il comble les defauts enumeres dans l'article). Il est profondement encre au systeme Unix mais il existe des interfaces sous Windows. ClearCase est utilise a grande echelle dans mon entreprise et c'est un veritable bonheur a utiliser. Les commandes sont simples, efficaces, il existe de nombreux utilitaires ( pour representer les arbres de maniere graphique par exemple). Bref, un logiciel dont devraitent s'inspirer bon nombre de projets libres (depuis que je connais ClearCase j'ai du mal a utiliser CVS, il est trop limite).

    • [^] # Re: Arch: un programme de gestion de version prometteur.

      Posté par  (site web personnel) . Évalué à 1.

      Personne n'a parle de ClearCase ici Où est-ce qu'on peut télécharger le source ? Est-il facile à compiler ? Quelles sont ses dépendances ? J'ai bien envie de l'essayer, mais j'ai peur que ce soit une trop grosse usine à gaz. D'un autre côté, je me demande pourquoi des projets comme Linux ou Apache ne s'en servent pas, s'il est aussi bien que ça.

      • [^] # Re: Arch: un programme de gestion de version prometteur.

        Posté par  . Évalué à 1.

        Non, c'est un logiciel très propriétaire dont les licences semblent coûter une fortune (quand je pense qu'un gros groupe réfléchit à acheter une nouvelle licence, c'est que le coût doit être exhorbitant). Par contre, les concepts utilisés sont interessants et pourraient-être repris dans un outil libre. Comme je ne suis pas spécialiste en outils de gestion de conf, je peux difficilement donner un jugement avantages/inconvénients par rapport à d'autres outils. Tout ce que je sais, c'est que, ce qui est plus important que l'outil de gestion de conf, ce sont les règles rigoureuses de développement qu'il faut appliquer sur un gros projet avec une grosse équipe (encore plus, si elle est internationale).

    • [^] # Re: Arch: un programme de gestion de version prometteur.

      Posté par  . Évalué à 1.

      Effectivement, j'utilise ClearCase depuis pas mal de temps (au boulot) et je le trouve remarquable. Je pense qu'il est basé sur un système de fichier virtuel : on choisi les versions et les branches que l'on veut voir apparaitre et aussitôt elles apparaissent dans le système de fichier ! De même, un utilisateur crée une nouvelle version et aussitôt, tout le monde en bénéficie sans avoir à l'importer.

      • [^] # Re: Arch: un programme de gestion de version prometteur.

        Posté par  . Évalué à 1.

        J'ai aussi utilise ClearCase et les concepts utilise sont TRES interessant.
        Ici tu parle des vues: tu choisit une vue de l'arbre du systeme et tu la monte
        (et tu peut te balader dans tout l'arbres avec des noms speciaux du genre @@....)

        ClearCase integre aussi un systeme de dependance ,avec un remplacement de Make pour contruire tes fichiers.

        SI a+b-> c , si tu travail sur d, au build pas besoin de fabriquer c, il peut etre dispo.

        Les outils clearcase permettent de suivre les modifications sur l'abre, on voit les merge, les branches, tout.

        J'aimerais voir un equivalent open source.

        Pour arche le tutorial m'apparais un peu long. Une version courte:
        creer un stockage, ajouter des fichier, les modifier, les remettre dans le stockage me manque.

      • [^] # Re: Arch: un programme de gestion de version prometteur.

        Posté par  . Évalué à 3.

        Je veux pas atténuer les qualités de ClearCase mais il n'est pas adapté à l'Internet (faible débit).

        • [^] # Re: Arch: un programme de gestion de version prometteur.

          Posté par  . Évalué à 2.

          Effectivement : il faut tj être connecté au serveur et je crois que pour faire du travail en multi-site (dans le cas où la bande passante n'est pas suffisante pour se connecter au premier serveur), il faut un serveur par site et un système de réplication.
          Et c'est vrai que c'est pas l'idéal dans le cadre de développement de logiciel libre.

          • [^] # Re: Arch: un programme de gestion de version prometteur.

            Posté par  (site web personnel) . Évalué à 0.

            yep c'est ca.
            Clearcase, c'est vraiment génial.
            Le gros pb que j'ai eu kan je suis passé à CVS (pour faire des tests), c'est que je comprenais pas pkoi un repertoire n'avait pas de version.
            Quand on commence par clearcase, on trouve CVS assez pauvre. Par contre CVS à un enorme avantage, il est vraiment orienté multisites connectés en bas débit (dev répartis par internet).
            AMHA, le jour ou un soft équivalent à clearcase existera dans le monde libre, de nombreuses compagnies feront des économies (c'est cher clearcase).

            • [^] # Re: Arch: un programme de gestion de version prometteur.

              Posté par  . Évalué à 1.

              J'ai utilise ClearCase et Subversion. En usage courant, je préfère Subversion (versionnage de répertoire aussi :-)). Par contre ClearCase a des outils périphérique puissant.

              > AMHA, le jour ou un soft équivalent à clearcase existera dans le monde libre

              Si tu envisages d'utiliser un gestionnaire de version, je te conseille vivement de jeter un coup oeil à Subversion. Actuellement c'est le plus aboutis (des non CVS) et il est parfaitement fonctionnel.

Suivre le flux des commentaires

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