Sortie de GNU Arch/TLA 1.2

Posté par (page perso) . Modéré par Nÿco.
Tags :
0
29
fév.
2004
GNU
Après l'annonce de Subversion 1.0, voici la nouvelle version du gestionnaire de version GNU Arch aka TLA (Tom Lord Arch).

La principale nouveauté est le support des changesets signés ("archive signing and integrity checking"). Cette fonctionnalité a été développée suite à la tentative d'insertion de backdoor dans Linux et aux piratages des serveurs Savannah et Debian.

Pour rappel, Arch est un gestionnaire de version permettant le développement centralisé et/ou distribué et dont le fonctionnement ne se calque pas sur CVS. Arch est bâti autour d'outils largement disponible comme tar, gzip, ftp, sftp. Les archives Arch sont ouvertes et facilement manipulables.

Arch gère les arborescences de façon globale : les commits sont atomiques (changeset).

Arch gère les méta données, le renommage/déplacement de fichier.

Arch permet aux développeurs de travailler sur plusieurs branches en parallèle. Arch permet quasiment tous les modes développements : centralisé (un repository, plusieurs développeurs), décentralisé (autant de repositories que de développeurs), et hybride (un repository central, et chaque développeur peut avoir son propre repository).

Bref, Arch est une alternative à Subversion, mais aussi à BitKeeper.
  • # Orthographe

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

    gestionnnaire: ça prend 6 n...
  • # Télécharger les sources

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

    C'est ici que ça se passe :
    http://wiki.gnuarch.org/moin.cgi/Official_20releases(...)

    Et plus globalement, ici, pour les packages et les tarballs quotidiens :
    http://wiki.gnuarch.org/moin.cgi/Getting_20Arch(...)

    Au fait, il n'y a plus de miroir GNU qui marche en France ?
  • # Re: Sortie de GNU Arch/TLA 1.2

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

    Quelqu'un a une experience d'utilisation de l'utilisation de arch pour un vrais projets (pas juste des test)?
  • # Re: Sortie de GNU Arch/TLA 1.2

    Posté par . Évalué à  3 .

    subversion vient de sortir en version 1.0
    arch semble être lui aussi un bon gestionnaire de version
    alors que reste il à BitKeeper, utiliser dans certains projets libres (kernel.org), tout en n'étant pas libre ?

    ce n'est pas de l'intégrisme pro-libre que je fais là, mais s'il existe des alternatives libres, pourquoi ne pas les utiliser, d'autant que ça les aiderait à évoluer plus rapidement encore qu'ils ne le font maintenant
    • [^] # Re: Sortie de GNU Arch/TLA 1.2

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

      Les alternatives sont peut-être encore un poil trop jeunes et n'ont pas atteint la masse critique d'utilisateurs pour que Linus Torvalds s'y essaye. Ceci dit, les développeurs du noyau sont tout à fait au courant de leur existence, certains les utilisent, et des utilisateurs de Arch (et de subversion certainement) font du lobbying en ce sens, et travaillent à améliorer Arch (et Subversion certainement) pour qu'il soit le plus adapté possible au développement du noyau. Il est clair que si|quand un des deux systèmes est|sera choisi de préférence à BitKeeper, il gagnera énormément en crédibilité.
      • [^] # Re: Sortie de GNU Arch/TLA 1.2

        Posté par . Évalué à  1 .

        en fait ça je le sais, j'ai eu l'occasion de suivre quelques discussions sur le sujet, mais je cherche, si ça existe, un article comparant les différentes solutions, pour pouvoir me faire une meilleure idée.

        Evidemment le meilleur moyen de se faire une idée serait de tester tout ça, mais je n'en ai personnellement pas l'usage.
        • [^] # Re: Sortie de GNU Arch/TLA 1.2

          Posté par . Évalué à  2 .

          Pourquoi ne pas aller lire les posts concernant la sortie de subversion 1.0 ?

          Beaucoup de choses ont été discutées, pleins de liens données, des comparatifs, bref pas mal de choses.

          Allez je suis généreux, je te file même l'url: http://linuxfr.org/2004/02/24/15522.html(...)

          Si avec ça tu as encore des questions, je peux plus rien pour toi :)
      • [^] # Re: Sortie de GNU Arch/TLA 1.2

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

        > n'ont pas atteint la masse critique d'utilisateurs pour que Linus Torvalds s'y essaye

        T'as pas du bien lire toutes les raisons qui font que Linus utilise BitKeeper. C'est avant tout parce que ses besoins sont tres complexes et qu'il ne se satisfait pas d'un outil inferieur. En gros, Subversion, c'est la 206, arch, c'est la mercedes mais Linus lui demande l'airbus A320 (a comparer principalement en terme de cible utilisateur et temps de developpement).

        Il a fallu plusieurs annees-hommes a plein temps pour acoucher bitkeeper et meme en l'etat, il ne satisfait pas tous les besoins de papa Torvalds. Donc ca m'etonnerait tres fort que autre chose que BitKeeper soit jamais utilise par Linus, parce que en plus, il est particulierement tetu et tenace (une qualite a mon avis dans le cadre de son activite mais qui a aussi ses inconvenients).

        > travaillent à améliorer Arch (et Subversion certainement)

        Pour ce qui est de subversion, je pense que tu reves aussi. Subversion a des ambitions tres moderees: remplacer CVS. C'est vraiment un bon remplacant, mais il ne fait pas grand chose de plus. Arch est deja beaucoup plus innovateur mais comme je le disais, il faudrait encore de nombreuses annees-hommes sur chacun de ces projets pour atteindre le niveau de fonctionnalite de bitkeeper.

        Donc pour ce qui est de Linus adoptant autre chose que bitkeeper, je pense que tu reves. En revanche, il me semble que d'autres developpeurs du noyau utilisent arch et un certain nombre de projets serieux sont passes a arch ou a subversion, donnant une credibilite a ces projets.
        • [^] # Arch ou SVn vs. BitKeeper

          Posté par . Évalué à  6 .

          Un paramètre supplémentaire me semble également assez important : les coûts de migration d'un système à l'autre.
          Le système de gestion de configurations est un outil mais ne produit rien en lui même (c'est à dire pas de code). Son utilisation est un coût qui est récupéré en qualité et souplesse. Une migration doit couter très cher (en temps, argent, énergie etc.) et ne se fait pas à la légère.
          • [^] # Re: Arch ou SVn vs. BitKeeper

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

            Ce qui implique qu'un nouveau système doit impérativement être supérieur à l'ancien pour pouvoir prétendre le remplacer. Quand une migration commence, c'est alors un effet d'avalanche qui s'ensuit.
            • [^] # Re: Arch ou SVn vs. BitKeeper

              Posté par . Évalué à  1 .

              Ce qui implique qu'un nouveau système doit impérativement être supérieur à l'ancien pour pouvoir prétendre le remplacer.

              Yep mais cela ne garanti pas malgré tout que la migration ne perdra rien au passage. C'est d'autant plus vrai que lorsque l'ancien système de gestion de conf avait des défauts que l'on contournait par des magouilles.
        • [^] # Re: Sortie de GNU Arch/TLA 1.2

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

          En gros, Subversion, c'est la 206, arch, c'est la mercedes mais Linus lui demande l'airbus A320

          Quelqu'un pourrait il expliquer ce que bitkeeper fait que arch ne fait pas ?
          • [^] # Re: Sortie de GNU Arch/TLA 1.2

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

            Je me reponds a moi meme :

            http://better-scm.berlios.de/comparison/comparison.html(...)

            Si quelqu'un a d'autres infos ...
            • [^] # Re: Sortie de GNU Arch/TLA 1.2

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

              Toujours d'apres le lien http://better-scm.berlios.de/comparison/comparison.html(...) , voila les choses que BitKeeper fait qu'Arch ne fait pas :

              * File and Directories Copies

              Arch No. Copies of files and directory structures are not supported.
              BitKeeper Yes. Copies are supported.

              * Per-File Commit Messages

              Arch No.
              BitKeeper Yes. It is possible to have a per-file commit message.

              Il y a aussi des points toujours en developpements liés à Arch, comme la documentation et les interfaces Web/GUI. Mais il y a aussi des points qui sont plus favorables à Arch qu'à BitKeeper.
          • [^] # Re: Sortie de GNU Arch/TLA 1.2

            Posté par . Évalué à  3 .

            Remarque triviale mais qui a son importance :
            pour que le kernel passe à GNU Arch, il faudra un solide moyen d'exporter les archives BitKeeper au format d'Arch, et ce sans passer par la passerelle CVS (ce qui entraînerait forcément des pertes d'informations : CVS n'a pas de notion de patchset, ...)
    • [^] # Re: Sortie de GNU Arch/TLA 1.2

      Posté par . Évalué à  6 .

      Utiliser tla pour le noyau, je suis pas sûr que ça soit faisable à l'heure actuelle, en particulier je me demande si ça se passe bien au niveau scalabilité pour l'utiliser sur des gros projets. De plus, tla évolue quand même encore assez vite, à mon avis il faut laisser un peu de temps passer pour être sûr que le logiciel est fiable.
      Enfin, quand bitkeeper a été choisi, tla/arch était loin d'être aussi mature qu'il l'est actuellement (bravo à tous les développeurs de arch pour le travail énorme fourni), et subversion ne correspond pas du tout à ce que linus veut.
      • [^] # Re: Sortie de GNU Arch/TLA 1.2

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

        subversion ne correspond pas du tout à ce que linus veut

        Tu pourrais étayer ? une url ?
      • [^] # Re: Sortie de GNU Arch/TLA 1.2

        Posté par . Évalué à  1 .

        "subversion ne correspond pas du tout à ce que linus veut. "

        Il manque quoi à Subversion vis-à-vis de Bitkeeper ?
        • [^] # Re: Sortie de GNU Arch/TLA 1.2

          Posté par . Évalué à  6 .

          A la base, subversion et bitkeeper ont pas grand chose à voir
          subversion est basé sur un modèle centralisé, où il y a un dépôt central alors que bitkeeper et arch sont basés sur un modèle distribué, où il n'y a pas nécessairement de dépôt central, mais où n'importe qui peut créer des branches locales, les publier, faire des fusions avec des branches situées à d'autres endroits sur le réseau.
          Il y a effectivement moyen de faire ça avec subversion et l'extension qui va bien si je me rappelle bien la news au sujet de la sortie de subversion 1.0, mais c'est une surcouche, et on est peut être limité par le modèle centralisé sous jacent, j'en sais strictmenet rien, j'ai pas essayé.
        • [^] # Re: Sortie de GNU Arch/TLA 1.2

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

          Pour faire cours car ca a été rabaché des milliards de fois a peu pres pour chaque news sur des gestionnaires de version: le coté distribué. Bon y'a d'autres raisons, mais celle la est la #1.
        • [^] # Re: Sortie de GNU Arch/TLA 1.2

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

          Dans la mesure ou tu utilise svk (http://svk.elixus.org/(...)) au dessus de subversion, il ne manque rien, et tu as l'avantage de garder un jeu de commande similaire (mais étendu) à celui de CVS.
    • [^] # Re: Sortie de GNU Arch/TLA 1.2

      Posté par . Évalué à  2 .

      Faut relativiser "puissament".

      Que Linux ait besoin du top du top en matière de gestionnaire de version, je comprends. Mais tes critères ne sont pas ceux de Linux. Lit la doc de subersion et arch en ayant en tête tes besoins et pas en imaginant que ton projet va devenir aussi complexe à maintenir que Linux.

      Une gestionnaire de version puissant ne replace pas de bon développeurs !
      D'ailleur Linux c'est longtemps passé de gestionnaire de version...
      De gros projects comme Gnome/KDE/Mozilla sont sous CVS sans que ça pose de gros problème.

      Faut relativiser.
      • [^] # Re: Sortie de GNU Arch/TLA 1.2

        Posté par . Évalué à  5 .

        J'aimerais bien que gnome et freedesktop passent à qqchose de plus puissant que cvs ;) Un support des changesets me parait maintenant quasiment indispensable :)
  • # Re: Sortie de GNU Arch/TLA 1.2

    Posté par . Évalué à  7 .

    Un autre truc qui marche très bien avec arch, c'est la maintenance d'une branche stable d'une branche de développemnt en parallèle. Si l'on prend garde à avoir des changesets "clean", c'est à dire des changesets contenant un seul changement, et pas un mélange de corrections de bugs divers et de nouvelles fonctionnalités, alors il est très facile de récupérer les corrections de bugs faits dans la branche de développement pour les appliquer à la branche stable: il suffit de faire un tla replay archive/branche-patch-xx, et tla récupère automatiquement le patch correspondant dans la version de développement et l'applique à la version stable. Ca marche évidemment même si les fichiers ont été déplacés/renommés. C'est un énorme progrés par rapport à cvs où la gestion de branches stables demande beaucoup plus de rigueur malheureusement :-/
    • [^] # Re: Sortie de GNU Arch/TLA 1.2

      Posté par . Évalué à  2 .

      C'est un énorme progrés par rapport à cvs où la gestion de branches stables demande beaucoup plus de rigueur malheureusement :-/

      Oui cela demande de la rigueur mais pas plus que pour Arch. Je suis dailleurs persuader que d'avoir un peu de rigueur ne peut être que bénéfique lorsqu'on se lance dans du développement.

      [MaVie]
      Je me suis lancé définitivement dans un processus d'adoption de Arch pour mes développement (aussi bien pro que perso) et ça déchire ! Je compte bien me séparer peu à peu de CVS même si il a encore de beaux jours ici :) (ben oui l'apprentissage est tout de même assez pénible).
      [/MaVie]
      • [^] # Re: Sortie de GNU Arch/TLA 1.2

        Posté par . Évalué à  2 .

        Avec arch, le seul truc à faire, c'est de pas tout mélanger lors d'un commit. Avec cvs, je galère chaque fois que je veux backporter un changement entre version de developpement et version stable. En fait je sais pas trop comment faire simplement ;)
        Un autre truc pénible avec cvs, c'est de rechercher à l'aveugle le commit qui a tout cassé. Je suis en train de faire ça a coup de -D "x days ago" et c'est quand même pénible :-/
        • [^] # Re: Sortie de GNU Arch/TLA 1.2

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

          pour trouver le commit qui a tout cassé, le bon truc c'est d'utiliser tkcvs: sur le fichier que tu suspectes tu regardes tous les log et un click sur le delta te donne la différence graphique entre les deux version seélectionnées. vraiment très agréable et très rapide
  • # Re: Sortie de GNU Arch/TLA 1.2

    Posté par . Évalué à  1 .

    J'ai cru comprendre qu'il y avait eu un fork entre deux versions des outils Arch. Quelqu'un peut nous dire où ça en est ?
  • # décentralisation

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

    Je démarre un projet en local, pour faire des commits très fréquents. Ensuite un développeur est intéressé, je dépose un repository sur un serveur sur lequel on commit tous les deux. Je part dans la montagne sans connexion internet, je me fait une copie du repository sur mon portable qui me permet de travailler tout en bénéficiant de la gestion de version, quand je rentre j'envoi la sauce sur le serveur.

    Est-ce ce comme ça la vie avec Arch ? Parcequ'avec cvs c'est pénible à gérer ce genre de chose...
    • [^] # Re: décentralisation

      Posté par . Évalué à  4 .

      Avec arch, tu aurais plutot un repository sur ta machine principale, un repository sur ton portable, qui serait probablement crée à partir du repository de ta machine principale (si t'as qu'un portable, ça simplifie un peu, t'as juste un repository et puis voilà).
      Pour que l'autre développeur puisse participer, tu publierais ton archive principale sur un site public en lecture seule. L'autre développeur peut alors créer une branche à partir de cette archive principale et travailler dessus.
      Ensuite, pour intégrer tous les changements entre ton portable, ta machine principale et les changements de l'autre développeur, le plus simple c'est d'avoir les 3 archives publiées qqpart sur le net (ou d'avoir un accés ssh ou webdav privé vers ces machines), et arch est alors capable de fusionner les changements en provenance de n'importe quelle branche vers n'importe quelle autre branche. Tu peux donc récupérer tous les changements faits sur ton portable et par l'autre développeur et les intégrer dans ton repository local facilement.
    • [^] # Re: décentralisation

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

      Tu fais pas une copie du "repository". Tu fais un branche dans ton archive locale.

      # création de l'archive
      tla make-archive toto@vacances--local ~/arch/local/
      tla my-default-archive toto@vacances--local
      # création de la branche
      tla archive-setup --vacances--1.0

      # ensuite tu établie une relation de filialiation entre ta branche locale et l'officielle
      tla tag toto@officiel--projects/--main--1.0 --vacances--1.0
      tla cacherev --vacances--1.0--base-0

      # tu fais ensuite des changesets propres
      vim `tla make-log`
      tla commit
      ...

      # et quand tu reviens, tu merge soit les changesets, soit la branche
      tla register-archive sftp://monportable/home/arch/local(...)
      tla star-merge toto@vacances--local/--vacances--1.0

      # ensuite tu règle les conflits

      tla log-for-merge >> `tla make-log`
      vim `tla make-log`

      tla commit

      Bon, il y a certainement d'autres méthodes, recettes, trucs, etc ...
      mais moi j'en suis que là pour l'instant ;)
      • [^] # Re: décentralisation

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

        Merci, ça à l'air très prométeur, bien qu'assez déroutant, j'imagine qu'il faut une bonne période d'adaptation.
      • [^] # Re: décentralisation

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

        Moi je dis bravo parce que c'est vrai que c'est un besoin relativement courant.

        Cela dit, un gros avantage de subversion, c'est sa simplicite. J'ai rien eu a apprendre pour passer de cvs a subversion et ca c'est appreciable. Mais j'aimerai bien pouvoir faire ce qui vient d'etre decrit.

        Notamment, il y a le cas ou qq'un veut faire un fork d'un projet et ou il est quand meme interessant de recuperer tout l'arbre de version du premier projet.
  • # codeville

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

    Est-ce que quelqu'un connait codeville ?

    http://bitconjurer.org/codeville/(...)


    Why yet another version control system? All other version control systems require that you keep careful track of the relationships between branches so as not have to repeatedly merge the same conflicts. Codeville is much more anarchic. It allows you to update from or commit to any repository at any time with no unnecessary re-merges.

    Codeville works by creating an identifier for each change which is done, and remembering the list of all changes which have been applied to each file and the last change which modified each line in each file. When there's a conflict, it checks to see if one of the two sides has already been applied to the other one, and if so makes the other side win automatically. When there's an actual not automatically mergeable version conflict, Codeville behaves in almost exactly the same way as CVS.


    A l'inverse des autres il a l'air d'être d'une simplicité déconcertante. Je dit ça en me basant sur la page de présentation, j'ai jamais essayé.
    • [^] # Re: codeville

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

      tla est également capable de n'appliquer que les patches nécessaires lorsque tu fusionne le changeset de quelqu'un d'autre. Il se souvient de tous les patches appliqués, et ne prend que les nouveaux. Outre son côté distribué, un des points forts de Arch est sa capacité à fusionner les changesets. De très nombreux modes de fonctionnement et options sont disponibles, afin de rendre cette opération très fréquente la moins pénible et la plus sûre possible.
  • # Re: Sortie de GNU Arch/TLA 1.2

    Posté par . Évalué à  2 .

    Bonjour,

    J'ai eu a me servir pendant un certain temps de Clearcase, et je dois avouer que l'experience ne fut pas si mauvaise...

    D'ailleurs, je me demandais si il y avait des projets visant a faire un GUI avec des fonctionnalites comme le TreeView, qui etait assez pratique. ( J ai deja vu CVSGraph, mais je ne sais pas si ca va aussi loin, et surtout si qqch pour Arch existe )

    Entk, en ce qui me concerne, je prefere me servir de ces outils via un GUI ( sans doute histoire de mieux visualiser ce que je fais ), et il me semble que Arch n'est helas pas encore tres bien fourni a ce niveau.
    • [^] # Re: Sortie de GNU Arch/TLA 1.2

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

      Le problème, c'est que Arch évolue très vite, et qu'il est donc difficile de faire une interface graphique qui couvre l'intégralité de ses capacités. Par contre, les capacités de base de Arch sont stables depuis longtemps maintenant, et certains ont donc commencé à travailler sur des interfaces graphiques qui permettent d'exploiter ces capacités. C'est pas encore sublime, mais c'est un bon début.

      Interfaces graphiques pour arch/tla :
      http://wiki.gnuarch.org/moin.cgi/GUI_20Front_2dends(...)
    • [^] # Re: Sortie de GNU Arch/TLA 1.2

      Posté par . Évalué à  2 .

      Y a un petit frontend pour Emacs mais il n'a pas de license donc je ne connais pas les conditions d'utilisation. C'est un lien qu'on m'a donné sur IRC (encore lui): http://sacha.free.net.ph/notebook/emacs/vc-arch/vc-arch.el(...)

      A consommer sans modération mais tout en conservant à l'esprit que son utilisation n'est peut être pas libre.
      • [^] # Re: Sortie de GNU Arch/TLA 1.2

        Posté par . Évalué à  2 .

        J'ai décidé de reprendre le développement de vc-arch pour qu'il s'intègr e complètement à vc.

        Le travail va être long mais j'ai déjà assez bien avancé.

        Je mettrais à dispo une archive ARCH/Tla disponible d'ici la fin de la semaine.
        • [^] # Re: Sortie de GNU Arch/TLA 1.2

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

          un mode vc-... c'est bien, mais existe-t-il un équivalent de PCL-CVS ? (M-x cvs-update)
          • [^] # Re: Sortie de GNU Arch/TLA 1.2

            Posté par . Évalué à  1 .

            Pas à ma connaissance, mais si tu veux le faire ;) Perso je n'utilise jamais PCL-CVS mais d'après les echos que j'en ai, c'est plutôt pas mal.

            Enfin je veux regarder mais je promets rien (c'est que ça prend du temps tout de même).
            • [^] # Re: Sortie de GNU Arch/TLA 1.2

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

              C'est completement génial, tu veux dire !

              le vc-mode, c'est bien pour travailler sur plusieurs fichiers indépendament, mais pour avoir une vue globale, PCL-CVS, c'est carrément le top. M-x cvs-update RET, hop, la liste des fichiers modifiés. `=' sur un des fichiers, et hop, le diff entre la version locale et l'archive. 'm' sur plusieurs fichiers pour les marquer, 'c' pour commit, il est appliqué sur tous les fichiers marqués. Je ne parle pas de l'intégration avec ediff pour avoir une visualisation conviviale des diffs, ...
              • [^] # Re: Sortie de GNU Arch/TLA 1.2

                Posté par . Évalué à  1 .

                Ah ben oui effectivement ;) Bon je me pencherais dessus aussi et puis qui sait je m'y mettrais peut-être :)
      • [^] # Re: Sortie de GNU Arch/TLA 1.2

        Posté par . Évalué à  2 .

        En général, sacha chua fait du GPL. Tu peux toujours lui demander sur IRC ceci dit ;)
  • # Un autre VCS

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

    un autre gestionnaire de version libre et trés intéressant est Monotone : http://www.venge.net/monotone/(...)
    Mais il est encore assez jeune et moins "utilisable" que Arch.
  • # Port OpenBSD TLA-1.2

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

    J'ai mis à jour mon port (en test, pas encore intégré à l'arbre officiel des ports OpenBSD) OpenBSD pour la version 1.2 de tla ce WE. Tous les tests intégrés à tla fonctionnent correctement ('make test' lors de la compil de tla)

    Si certains d'entre vous veulent tester et me faire un compte-rendu de test, j'en serai très content.

    L'archive du port tla-1.2 (créé et testé sur OpenBSD 3.4/i386) : http://foxy.free.fr/OpenBSD/ports_tla-1.2.tar.gz(...)

    foxy at free.fr
  • # Outils pour GNU Arch/TLA 1.2 ?

    Posté par . Évalué à  3 .

    Actuellement, on utilise CVS à la boite.
    C'est super bien intégré à Eclipse, on a aussi une interface
    web( cvsweb ) et on peut aussi utiliser TortoiseCVS.

    J'ai vu que subversion proposait déjà tous ces outils.

    Qu'en est-il de arch ?

    Il nous faudrait au moins un plugin pour Eclipse.
    • [^] # Re: Outils pour GNU Arch/TLA 1.2 ?

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

      Il nous faudrait au moins un plugin pour Eclipse.

      Et bien développe le, où sponsorise son développement.

      Concernant le cvsweb, il y a un équivalent:
      (demo): http://arch.bluegate.org/cgi-bin/viewarch.cgi(...)
      Attention cet outil ne fonctionne pas comme cvsweb, c'est avant un browser de patch (et en cela il reprend le fonctionnement de Arch), la page principale affiche la liste des patches et non l'arborescence de fichier : http://arch.bluegate.org/cgi-bin/viewarch.cgi/lord@emf.net--2004/tl(...)
      On peux tout de même accéder à l'arborescence en sélectionnant un patch particulier:
      http://arch.bluegate.org/cgi-bin/viewarch.cgi/lord@emf.net--2004/tl(...)

      De plus ce ne sera certainement pas ce que tu recherche étant donné qu'il n'y pas tout les artifices graphiques qui existent dans les browsers pour CVS.

      A voir aussi la liste complète des outils:
      http://wiki.gnuarch.org/moin.cgi/Arch_20Revision_20Browsers(...)
      • [^] # Re: Outils pour GNU Arch/TLA 1.2 ?

        Posté par . Évalué à  3 .

        Et bien développe le, où sponsorise son développement.

        En regardant les discussions qui ont eu lieu sur arch avec la sortie de subversion 1.0.0 et de tla 1.2 j'ai l'impression que la gestion de conf avec arch est assez différente de ce qui se fait plus classiquement. Est-ce que cela ne va pas être un problème pour développer des plug-ins pour des IDE. En clair, le développement de subclipse (le plugin subversion pour Eclipse) était relativement « facile » à faire puisqu'au final sont fonctionnement serait très proche du très bon plug-in pour CVS. Est-ce que le développement d'un plug-in pour arch peu suivre ce schéma (on prend les fonctionnalités et l'ergonomie du plug-in CVS et on adapte) ou est-ce qu'il sera nécessaire de remettre de tour remettre à plat de ce côté là ?
        • [^] # Re: Outils pour GNU Arch/TLA 1.2 ?

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

          Il y a certainement de la remise à plat à faire. Pour des opérations génériques (vérifier l'état de ses fichiers locaux par rapport à ce qui est stocké dans le dépôt, se synchroniser avec un autre serveur, enregistrer ses changements dans le dépôt) l'interface peut rester très proche, même si pas mal de choses doivent changer sous le capot. Par contre, pour le reste tout est à revoir car CVS et Subversion se focalisent sur les changements par fichier (on a donc des interfaces où l'on navigue dans le système de fichiers et où on peut consulter chaque fichier indépendamment -- choses qui sont faisables avec Arch bien sûr) alors qu'Arch se focalise sur les changements par lots (il faut donc un interface pour consulter le contenu d'un lot, pour lister les changements qui ont eu lieu entre le patch-43 et le patch-57 de tel individu, par exemple). De plus, Arch permet une énorme flexibilité pour les sources des patches (on en prend un à droite, un à gauche, etc.) alors que CVS et Subversion ne s'adressent qu'à un serveur. Là où dans l'interface on se contentait d'avoir une boîte de dialogue "Paramètres du serveur" dans CVS, il faut une liste de serveurs dans Arch, par exemple.

          Ceci dit, BitKeeper fonctionne aussi par patchsets, et dispose d'excellentes interfaces graphiques d'après la rumeur, il y a donc peut-être des idées à lui emprunter.

          Enfin, vu la flexibilité de Arch, il est fort possible que l'on voit apparaître des interfaces qui n'implémentent que certains aspects de celui-ci, tout comme TortoiseCVS ne supporte pas toutes les commandes de CVS.
          • [^] # Re: Outils pour GNU Arch/TLA 1.2 ?

            Posté par . Évalué à  3 .

            CVS et Subversion se focalisent sur les changements par fichier (on a donc des interfaces où l'on navigue dans le système de fichiers et où on peut consulter chaque fichier indépendamment -- choses qui sont faisables avec Arch bien sûr) alors qu'Arch se focalise sur les changements par lots (il faut donc un interface pour consulter le contenu d'un lot, pour lister les changements qui ont eu lieu entre le patch-43 et le patch-57 de tel individu, par exemple)

            En fait pas exactement sur Subversion étant donné que les commits sont atomiques la notion de changement par lot existe bel et bien. C'est d'ailleurs le truc le plus déroutant pour les utilisateurs de CVS car lorsque l'on met un mot clé $Revision$ dans un fichier géré par svn, le nombre n'est pas comme sur CVS une version du fichier mais la révision du répository durant laquelle le fichier a été modifié en dernier: donc le numéro du lot dans lequel le fichier a été modifié la dernière fois. D'ailleurs ce type de fonctionnalité (navigation par changeset) n'est pas à ma connaissance implémentée dans subsclipse.
  • # Re: Sortie de GNU Arch/TLA 1.2

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

    Le libre c'est fantastique: cela fait plusieurs années qu'on se coltine CVS, que tout le monde hesitait à avancer dans les systèmes de suivi de version.

    Et puis, un beau jour Linus déciude d'utiliser un produit non-libre car CVS ne lui convient pas.

    Et là, quelque mois après les projets et les avancées dans les logiciels de suivi de versions sortent à tout va. Il doit même y avoir une certaine concurence entre les devellopeurs d'Arch et de Subversion.
    Cela prouve encore que le logiciel libre est plus vivace que jamais, et est capable même sans hierarchie ou organisation precise de coutourner très rapidement les difficultés.

    Je pense que l'on est aujourd'hui dans la bonne voie.
    • [^] # Re: Sortie de GNU Arch/TLA 1.2

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

      Si d'un coté, les trolleurs ont trouvé un nouveau sujet, il faut avouer que comme les objectifs de arch et subversion ne sont pas tout à fait semblables, il va devenir intérêssant de se pencher sur quel outil de gestion/contrôle de version utiliser. N'oublions quand même pas que CVS, même étant vieux, rempli encore très bien son rôle et qu'utiliser arch ou subversion pour ne pas se montrer has been me fait bien rire.
      • [^] # Re: Sortie de GNU Arch/TLA 1.2

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

        Tu te fais un peu des idées : pour l'instant, il n'y a pas encore de trolleurs (ça viendra avec l'accroissement de popularité), et je ne connais pas beaucoup de gens qui utilisent Arch ou Subversion par peur d'être has-been. C'est simplement l'attrait de la nouveauté qui joue, je pense.
        • [^] # Re: Sortie de GNU Arch/TLA 1.2

          Posté par . Évalué à  1 .

          Oui, je suis un peu surpris par les commentaires dans les news sur subversion 1.0 ou arch 1.2, y a aucun des deux threads qu'a dégénéré en troll, félicitations à tous les participants ;)
        • [^] # Re: Sortie de GNU Arch/TLA 1.2

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

          pour l'instant, il n'y a pas encore de trolleurs
          Faut leur laisser le temps de tester tout de même :)

          C'est simplement l'attrait de la nouveauté qui joue, je pense.
          Je n'ai pas dit l'inverse, bien au contraire, c'est plus justement parce que c'est nouveau que certains vont passer des nuits blanches à les comprendre eux-deux, alors que CVS leur suffit amplement (c'est comme de passer du 2.4 au 2.6.0-pré_quelque_chose alors que tous les drivers marchent au poil sur un 2.4).

          Je pense, ama, que pour commencer à toucher à arch ou subversion, il faut déjà bien connaître cvs et surtout, avoir une très bonne connaissance de ses besoins en terme de versionning.
          Ceci n'étant que mon avis ...
          • [^] # Re: Sortie de GNU Arch/TLA 1.2

            Posté par . Évalué à  1 .

            Un trolleur qui teste avant de troller!?

            Personnellement, et pour faire un commentaire qui va dans le sujet : cvs ne me plaît pas ; par contre, j'utilise arch depuis une quinzaine de jours, et j'en suis assez content.

            Snark
          • [^] # Re: Sortie de GNU Arch/TLA 1.2

            Posté par . Évalué à  0 .

            « pour l'instant, il n'y a pas encore de trolleurs
            Faut leur laisser le temps de tester tout de même :) »

            Tu rigole ?
            Pour bien troller sur un soft, pas la peine de l'avoir essayé. (au contraire presque)
            • [^] # Re: Sortie de GNU Arch/TLA 1.2

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

              Ah mais pas du tout. Pour vraiment bien troller sur un sujet, il faut le maîtriser : savoir quels sont les faiblesses et les points sensibles du sujet, comment les insérer dans la conversation sans que ça ne se voit trop, planquer un mensonge qui fait violemment réagir en plein milieu de trucs raisonnables - de manière à ce que ce soit celui qui réponde qui donne l'impression de mettre le feu. Lancer un vrai troll, c'est difficile, mais quand ça pète, ça fait du dégât.

              Ne confondez pas le vrai troll avec les pauvres petits « sapusaipalibre » et autres piques visibles sur LinuxFr : ils sont au vrai troll ce qu'un ninja en pyjama jaune fluo est aux assassins de la nuit.
          • [^] # Re: Sortie de GNU Arch/TLA 1.2

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

            Je pense, ama, que pour commencer à toucher à arch ou subversion, il faut déjà bien connaître cvs et surtout, avoir une très bonne connaissance de ses besoins en terme de versionning.

            Je pense justement le contraire. Etant donné le fait que le paradigme de arch est vraiment différent de celui de CVS (mode distribué, changesets atomiques, ...) je pense qu'apprendre arch directement est plus facile sans etre "pollué" par des habitudes liées à l'utilisation de CVS.

            Commencer par apprendre arch est aussi (ama) une bonne idée pour une autre raison : arch est nettement plus facile à installer sur sa machine perso (pas de serveur à installer/configurer/sécuriser). Alors pourquoi se priver des fonctionalités supplémentaires qui simplifient la vie (renommage/déplacement, signature numérique intégrée, ...) ?

            Apres, je ne dis pas que maitriser CVS est une mauvaise chose (c'est toujours utile étant donné le fait qu'il est encore très majoritairement utilisé et pour encore longtemps probablement ...).
            • [^] # Re: Sortie de GNU Arch/TLA 1.2

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

              Il faut surtout comprendre qu'elles sont les concepts de la gestion de version.

              Que ce soit CVS, RCS au niveau fichier ou Arch, BitKeeper, Subversion au niveau repository, les concepts sont les mêmes: le suivi de modification, l'enregistrement des changements, le stockage des versions successives. Ensuite il n'y a que la façon de les appliquer et les manipuler qui change.

              Il ne faut pas se focaliser sur les implémentations, mais comprendre les concepts. Cela permet d'utiliser tout type d'implémentation.

              [OT]
              Exemple grossier: la secrétaire a qui l'école a appris MS Word au lieu de lui apprendre le traitement texte. La pauvre secrétaire ne sait que cliquer dans un menu bien particulier pour effectuer une tâche, si bien que si on lui change son MS Word, elle est perdue, elle ne sait plus où cliquer. Elle n'a pas les bases, les concepts qu'il y a derrière le traitement de texte. On ne lui a appris que des procédures.

              Apprendre un logiciel en particulier, cela va à l'encontre de l'informatique Libre. La liberté demande de la connaissance et de la compréhension afin de pouvoir passer d'un logiciel à l'autre.
              • [^] # Re: Sortie de GNU Arch/TLA 1.2

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

                Je suis tout à fait d'accord avec toi/vous (je sais jamais s'il faut vouvoyer sur LinuxFr ...). Mais on peut apprendre ces concepts aussi bien avec arch qu'avec CVS. Je dis juste que commencer par arch permet de bénéficier de nouvelles fonctionalités et d'une simplicité de mise en oeuvre que CVS ne posséde pas. De plus l'aspect distribué de arch s'adapte (ama toujours) mieux aux projets libres qui ont un développement distribué par nature.
      • [^] # Re: Sortie de GNU Arch/TLA 1.2

        Posté par . Évalué à  1 .

        Tu dis ça pour ça http://www.sickless.net/acvs/(...) ?

        Ca se comprend ... :p
  • # Re: Sortie de GNU Arch/TLA 1.2

    Posté par . Évalué à  4 .

    Dans le même genre je suis tombé (toujours en discutant sur IRC) sur un autre gestionnaire avec un petit nom sympa: DARCS.

    En gros c'est un Arch light et beaucoup, beaucoup plus simple à prendre en main.

    C'est écrit en haskell (oh comme c'est beau) et il y a un backend VC pour emacs (vc-darcs).

    Je l'ai testé et c'est vrai que la prise en main est vraiment rapide.

    Le seul hic: ça manque de documentation. A noter que l'auteur du programme a écrit un très intéressant texte qui s'intitule: La théorie des patchs (en anglais aussi) très instructif.

    A essayer absolument, c'est assez bleuffant de facilité.

    darcs : http://www.abridgegame.org/darcs/(...)
    vc-darcs: http://www.emacswiki.org/elisp/vc-darcs.el(...)
    Theory of patches: http://www.abridgegame.org/darcs/manual/node7.html(...)
    Le manuel: http://www.abridgegame.org/darcs/manual/(...)
  • # Re: Sortie de GNU Arch/TLA 1.2

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

    Une nouvelle comparaison/description de Subversion et GNU Arch (en anglais)
    http://www.dwheeler.com/essays/scm.html(...)

Suivre le flux des commentaires

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