Subversion RC-1

Posté par  (site web personnel) . Modéré par Nÿco.
Étiquettes :
0
4
fév.
2004
Communauté
Subversion, le système qui vise à remplacer CVS, a sorti la première version candidate à la version 1.0.0 La nouvelle date un peu (25 janvier), mais la première version candidate à la version 1.0.0 de subversion est sortie.

Mais, qu'est-ce que subversion ?
C'est un logiciel de gestion de version, un système permettant de maintenir plusieurs versions d'un même fichier et d'en retenir l'historique (voir la définition wikipédia dans les liens).
Le système de gestion de fichier le plus connu est CVS (Concurrent Versioning System)

Pourquoi remplacer CVS ?
Bien qu'étant l'un des système de gestion de version les plus utilisés, CVS a quelques fonctionnalités qui font défaut... C'est pourquoi de nouveaux projets tel subversion sont né.

Qu'apporte subversion de plus par rapport à CVS ?
- Gestion des répertoires.
- Possibilité de renommer et déplacer des fichiers.
- Ajout de méta-données sur les fichiers et historique de celles-ci.
- Possibilité d'utilisation d'Apache comme serveur et de WebDAV /DeltaV comme protocole.
- Optimisation de l'utilisation de la bande passante
- Gestion simplifiée des fichiers binaires

En bref, plein de bonnes choses à essayer; la version 1.0 est proche et je ne peux que vous conseiller de tester... vous serez vite conquis.

Aller plus loin

  • # Re: Subversion RC-1

    Posté par  . Évalué à 4.

    Euh CVS sait deja faire du renommage/suppression/deplacement pour les fichiers et les repertoires, sans compter qu'il gère bien les répertoires (plus généralement les sources possédant une arborescence).
    Il sait aussi gérer les fichiers binaires, mais c'est vrai que c'était qqchose de perfectible (suffit d'indiquer l'extension des fichiers devant etre traités comme des binaires dans un fichier de conf).
    Par contre, ce que CVS ne permet pas de faire de facon aisée, ce sont les "reserved checkout", et ça, c'est qd meme dommage, surtout dés lors qu'on se retrouve a bosser a plusieurs sur un meme fichier ...
    Bref, pour avoir fait du CVS et du clear-case (l'outil de conf des entreprise qui coute super cher), le seul truc qui manque a CVS, c'est de pouvoir faire du "reserved checkout" plus facilement et plus efficace ...

    • [^] # Re: Subversion RC-1

      Posté par  . Évalué à 7.

      > Euh CVS sait deja faire du renommage/suppression/deplacement pour les fichiers et les repertoires

      CVS le fait mais de façon pas très classe il me semble et de façon non atomique (Le renommage c'est une suppression puis une création et donc perte de l'historique).

      Prend le temps de lire la doc de subversion et tu verras que subversion est clairement "potentiellement" meilleur.

      • [^] # Re: Subversion RC-1

        Posté par  . Évalué à 2.

        Je viens de la lire, et je trouve (c'est le point de vue d'un dev qui utilise CVS) que les améliorations restent légères par rapport à ce que permet déjà de faire CVS.
        Ca aurait été interessant d'apporter qqes "vraies" nouveautés non ?
        Alors lesquelles, hormis le "reserved checkout", je ne sais pas puisque c'est des nouveautés :-)
        Pour info, le "reserved checkout" permet de travailler sur un fichier sans que qq'un d'autre puisse le commiter pdt que vous travaillez dessus (on ne peut que le consulter), jusqu'a ce que vous l'ayez commité. Avec CVS, c'est "le 1er qui commit qui gagne", ca peut être génant ...

        • [^] # Re: Subversion RC-1

          Posté par  . Évalué à 1.

          Si tu veux ...
          On peut tout faire avec CVS en se débrouillant bien.
          Comme on peut faire de la programmation objet avec le C ... mais c'est mieux supporté avec le C++.

        • [^] # Re: Subversion RC-1

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

          Pourtant en cas de commits concomitants (héhé) CVS laisse les lignes suspectes bien marquées dans le fichier, charge après à toi de décider quelle modification est la bonne.

          Bien sur, ce n'est pas du "reserved checkout" à la WebDav, mais de là à dire que c'est "le 1er qui commit qui gagne" il y a un pas tout de même...

        • [^] # Re: Subversion RC-1

          Posté par  . Évalué à 2.

          je ne connais pas du tout cvs (pour être honnête je ne connais que source safe de MS), et en lisant ces posts je me pose une question :
          lors d'un commit, le fichier du serveur est-il écrasé ou fusionné ?

          Si il est fusionné, en quoi ça pose problème que "le 1er qui commit qui gagne" ? Le premier utilisateur archive sa modification, le suivant la sienne, et le résultat possède bien les 2 modifs, non ?
          le seul problème arrive si les 2 personnes modifient la même portion de code. Dans ce cas le verrou est nécessaire effectivement

          • [^] # Re: Subversion RC-1

            Posté par  . Évalué à 2.

            Le fichier du serveur n'est ni écrasé ni fusionné, ou alors je ne comprends pas ce que tu signifies par là. Le fichier est modifié de manière à contenir la version commitée + les diffs inverses pour refaire l'historique. Concernant la fusion, CVS ne le fait pas lors du commit. Il faut que la version à commiter soit "à jour". Donc la procédure c'est de mettre à jour son répertoire de travail (c'est là qu'est fait l'éventuel travail de fusion), qui est alors prêt à être commité. Si quelqu'un a commité juste avant toi et que ça pose problème, CVS ne te laisse pas commiter, il faut que tu refasses une mise à jour et le travail de fusion.
            Ca ne nécessite pas de verrous (mais il y a quand même possibilité d'en mettre).

            • [^] # Re: Subversion RC-1

              Posté par  . Évalué à 1.

              Le fichier du serveur n'est ni écrasé ni fusionné, ou alors je ne comprends pas ce que tu signifies par là. Le fichier est modifié de manière à contenir la version commitée + les diffs inverses pour refaire l'historique.

              Ce que j'appelle fusionné c'est ça :
              il y a un fichier sur le serveur, tu le récupère, tu fais des modifications. quand tu effectue le commit, le serveur repère les modifications et les effectue (et garde bien sûr le diff avec l'ancien état, ça va de soit). Comme ça, si quelqu'un a lui-même fait des modifications entre temps, elles ne sont pas perdues, et les tiennes sont cumulées.

              Comme tu décris la chose, je considère ça comme un écrasement, car personne ne peut faire une modification en même temps que toi.

              • [^] # Re: Subversion RC-1

                Posté par  . Évalué à 2.

                Je me suis peut-être mal exprimé, mais d'après tes 2 descriptions de fusion/écrasement, CVS fait plutot de la fusion : plusieurs personnes peuvent faire des modifications en même temps. Le commit se fait en deux commandes : update + commit, les conflits de fusion étant à régler suite à l'update, s'il y en a.

                Dans le cas simple où il n'y a pas de conflits (modifs dans des fichiers différents ou des endroits bien séparés), tout le monde peut travailler en même temps et à partir de la même version, puis chacun fait un update+commit qui se passera bien. Quel que soit l'ordre des commits, toutes les modifs seront cumulées dans la version "actuelle" du serveur.

                • [^] # Re: Subversion RC-1

                  Posté par  . Évalué à 1.

                  ouf :)

                  ça va alors, ça me paraissait le b a ba d'un truc de gestion de sources

                  je me mettrais bien à ce genre de trucs, je vais peut etre essayer arch pour mes projets perso.

                • [^] # Re: Subversion RC-1

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

                  Et si tu fais commit sans faire d'update préalable, ça fonctionne toujours...? ou peut-être ceci n'est pas possible à faire ?

                  • [^] # Re: Subversion RC-1

                    Posté par  . Évalué à 2.

                    Je n'ai jamais essayé, ça ne me semble pas une bonne pratique.
                    Si le fichier que tu as modifié n'a pas été modifié par quelqu'un d'autre, il doit l'accepter (éventuellement en disant bien de ne commiter que celui-là). Mais il me semble préférable de faire un update, vérifier que tout marche toujours, puis commiter, je pense qu'avec ce que tu proposes on peut se retrouver avec une version "courante" dans le repository qui ne compile plus.

                    • [^] # Re: Subversion RC-1

                      Posté par  . Évalué à 2.

                      dans ma boite on utilise source safe (MS), tout le monde bosse sur les memes fichiers en même temps, souvent pendant plusieurs heures sans archiver ses modifications, et il n'y a presque jamais de pb (on ne traite pas le même bug à plusieurs)

                      Je pense qu'avec un bon issue tracking histoire de pas faire la même chose que le collègue, ça ne peut pas poser de pb...

                      • [^] # Re: Subversion RC-1

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

                        En general, les problemes finissent par arriver. On m'a sorti tous les arguments possibles comme quoi il n'y avait pas besoin de fonctionner en mode fusion et que le mode "reservation" fonctionnait, dans la pratique, tu as besoin de la fusion. Par exemple, pour tracer un probleme, tu es conduit a rajouter des commandes de log dans plein de fichiers de ton programme. C'est temporaire et local, mais tu as besoin de le faire. Et la paf, tu tombes sur un fichier que qq'un d'autre a reserve pour travailler dessus. Autre probleme typique, les fichiers type config.h que tout le monde a besoin d'accomoder rapidement. Il y a toujours des situations ou il y a des bloquages et de la perte de productivite. CVS resout ca intelligemment.

        • [^] # Re: Subversion RC-1

          Posté par  . Évalué à 3.

          « Ca aurait été interessant d'apporter qqes "vraies" nouveautés non ? »

          Gestion des répertoires et commit atomiques, ça ne me paraît pas de "petites" nouveautés...

          • [^] # Re: Subversion RC-1

            Posté par  . Évalué à 8.

            C'est pas dangereux tous ces trucs atomiques ?

            -1 et -->[]

            • [^] # Re: Subversion RC-1

              Posté par  . Évalué à 4.

              pas en France

              -> -> []

              • [^] # Re: Subversion RC-1

                Posté par  . Évalué à 1.

                Les Ardennes sont très sûres (que ce soit par le sol ou par les airs)

          • [^] # Re: Subversion RC-1

            Posté par  . Évalué à 1.

            Et aussi le renommage et le déplacement des fichiers. On peu renommer un fichier et/ou le déplacer et son historique est conservé. Il y a aussi la gestion des branches et des tags qui est beaucoup plus simple car KISS powered.
            Mais la grande nouveauté par rapport à CVS est bien le commit atomique.
            Ce commit atomique permet, entre autre, de répliquer rapidement des correction de bugs d'une branche à l'autre.

            • [^] # Re: Subversion RC-1

              Posté par  . Évalué à 1.

              Oui, à propos des branches, il y a maintenant la possibilité de faire des merge consécutifs (avec CVS le diff est appliqué 2 fois si on ne prend pas garde).

        • [^] # Re: Subversion RC-1

          Posté par  . Évalué à 3.

          Pour info, le "reserved checkout" permet de travailler sur un fichier sans que qq'un d'autre puisse le commiter pdt que vous travaillez dessus (on ne peut que le consulter), jusqu'a ce que vous l'ayez commité. Avec CVS, c'est "le 1er qui commit qui gagne", ca peut être génant ...

          ah ?
          et que font les commandes "watch" et "edit" ?

          http://www.cvshome.org/docs/manual/cvs-1.12.5/cvs_10.html#SEC92(...)

          • [^] # Re: Subversion RC-1

            Posté par  . Évalué à 1.

            Elles n'empêchent pas le "premier qui commit qui gagne" pour autant.
            Elles ne font que de l'incitation. Quand on est nombreux sur une même base CVS, l'incitation ne suffit pas toujours...

        • [^] # CVS et les Reserved checkout

          Posté par  . Évalué à 1.

          CVS permettait de le faire auparavant.
          puis cette fonction est passée en status "deprecated".

          parce que cette fonctionalité n'est pas pratique du tout.

          Le grand principe de CVS, c'est le MERGE.

          alors Subversion, je veux bien... faut voir.

        • [^] # Re: Subversion RC-1

          Posté par  . Évalué à 1.

          sur mon projet on a "resolu" le reserved checkout a coup de cvs admin -l et -u ce qui n'est pas top car ca sous entend que tout le monde a acces au commande admine ce qui peu conduire a des catastrophes si quelqu'un joue avec cvs admin -o.
          Sinon le fait que cvs ne gere pas le reserved checkout et un choix phylosophique de l'equipe de developpement de CVS. Si plusieurs personnes travaillent sur un meme fichier ils sont sensés se prevenir a coup de cvs edit ... mais edit n'interdit pas de remonter un fichier edité par qq1 d'autre. Je pense que le mode edit+merge est tres bien pour les projet developé sur le net , ca t'evite d'envoyer des mails a plein de gens pour qu'il deloquent leurs fichiers et te laisse travailler...mais si tu travail sur un projet où les gens ne sont pas trop conserné par ce qu'ils font tu t'appercois que le merge a des defaut aussi ... J'ai deja vu des fichiers remontés dans la repository avec des conflit dedans ...

          • [^] # Re: Subversion RC-1

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

            > si tu travail sur un projet où les gens ne sont pas trop conserné par ce qu'ils font

            A mon avis, dans ce genre de situation, tu peux t'attendre a des milliers de problemes, et pas seulement cote gestion de source.

            Cela dit, je pense que CVS reste un outil tres adapte meme pour ce genre de situation. En gros, les gens font n'importe quoi donc il te faut plus de controle: tu envoies tous les diff par mail, et comme ca tu controle.

            Tu peux aussi aller vers des mesures de controles en faisant touner des scripts qui autorisent ou pas un commit. Tu peux meme ouvrir une branche reservee au neuneu et n'integrer leurs modifs que lorsque tu as valide qu'ils avaient fait leur boulot correctement.

            Sinon, tu peux passer a une solution plus musclee, genre bitkeeper, qui permet de valider chaque commit manuellement, ou qui permet de developper dans un sous-deposoir qui n'est remonte sur le deposoir principal que lorsque tu le choisis.

            Je connais des boites qui gerent des projets de plusieurs millions de lignes sous CVS sans aucun probleme.

            > J'ai deja vu des fichiers remontés dans la repository avec des conflit dedans ...

            Je qualifierai ca d'incompetence. C'est des developpeurs tes neuneus ?

            • [^] # Re: Subversion RC-1

              Posté par  . Évalué à 1.

              oui, mes neuneu sont des developpeurs ... ca fout la trouille hein ... en fait ils ne meritent pas trop l'appelation de developpeur ...
              bugger serait plus addapté, comme l'inverse de debugger ... et regardes sur un dico anglais ce que ca veut exactement dire et tu sauras ce que je pense de mes neuneu ...
              Sinon, on filtre les commit et c'est vraie que ca limite bien les problèmes, mais personne n'est designé pour vérifier que les modifications faites par les autres sont valides...

        • [^] # Re: Subversion RC-1

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

          Une vraie nouveauté pour un produit gpl de ce genre aurait été par exemple la gestion de fiches de suivis, comme dans clearcase, mais optionnelles bien évidement.

          Ca peut manquer. par exemple, dans la boite ou je bosse actuellement, cvs a été rejeté parce qu'il ne gère pas les fiches de suivi. C'est bien dommage, car en entreprise, quand il y a 200 développeurs, ca peut être utile.

    • [^] # Re: Subversion RC-1

      Posté par  . Évalué à 4.

      CVS sait deja faire du renommage/suppression/deplacement pour les fichiers et les repertoires

      ok, mais ça n'est quand même pas du tout pratique. Subversion va peut-être améliorer ces processus

      il gère bien les répertoires

      s/bien//
      Il n'intègre pas de processus identique aux fichiers pour les répertoires. Je ne vois pas trop ce que ça pourrait donner, mais ça pourrait être quand même sympa d'avoir la même gestion qu'avec les fichiers

      les "reserved checkout"

      C'est quoi ?

      • [^] # Re: Subversion RC-1

        Posté par  . Évalué à -1.

        ça bloque l'accès en écriture à un fichier s'il quelqu'un d'autre est en train de travailler dessus. Et effectivement, je pense moi aussi que c'est indispensable quand on travaille en équipe ...

        • [^] # Re: Subversion RC-1

          Posté par  . Évalué à 1.

          "ça bloque l'accès en écriture à un fichier"
          autant utiliser rcs... Je condidère ca comme une regression.

    • [^] # Re: Subversion RC-1

      Posté par  . Évalué à 3.

      Renomage et deplacement de fichier et de repertoire avec CVS ? Ah ben si tu sais faire ca simplement (sans magouiller sur le serveur CVS) et en gardant l'historique des modifs et des anciens noms, explique moi ça, parceque j'ai jamais vu...

      Les seuls trucs (crades) que j'ai vu sont de ce style: http://www.cs.utah.edu/dept/old/texinfo/cvs/cvs_14.html(...)

      • [^] # Re: Subversion RC-1

        Posté par  . Évalué à 0.

        deplacement de fichiers, faut pas pousser, ca se fait trés bien, sans "magouille" sur le serveur (relis la doc ... -> http://www.cvshome.org/docs/manual/cvs-1.11.10/cvs_7.html#SEC70(...))
        Aprés, c'est vrai que le renomage de répertoire est discutable et que c'est plus commode de le faire en direct sur le serveur ... mais je trouve que ca reste "maigre" comme amélioration (en lisant l'article sur dlfp, on dirait que CVS ne sait pas le faire alors que c'est faux).
        Mais ca n'est qu'un point de vue ... si dans tes projets tu as souvent besoin de renomer des répertoires, c'est sur que c'est génant.

        • [^] # Re: Subversion RC-1

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

          > deplacement de fichiers, faut pas pousser, ca se fait trés bien, sans
          > "magouille" sur le serveur

          Wahoo, trop fort !

          Moi, je le fait avec "mv" et "cp", et sans CVS :

          cp toto.c toto.c.bak
          mv toto.c titi.c

          Et hop, ça roule !!!


          Ta solution, c'est vraiment une bidouille :

          * Pas de gestion efficace de l'historique. Normalement, on ne conserve que les diffs, là, il faut tout dupliquer

          * Pas de gestion correcte des logs. un "cvs log" sur le nouveau fichier ne donne pas l'historique avant le renomage

          * Pour naviguer dans l'historique, bonjour ! Exit le cvs annotate, cvs diff, ...

          • [^] # Re: Subversion RC-1

            Posté par  . Évalué à 0.

            Ca n'est pas ma solution mais celle préconisée par les auteurs de CVS; si c'est tu trouves ca nul, tu peux leur dire (mais je suis sur que tu l'as déjà fais).
            Ensuite, pour ma part, qd je vire/deplace un fichier, je mets dans le commentaire du commit le pourquoi du comment et le nouveau nom ...
            Bon, je me suis bien amusé avec ce troll, j'arrête là ...

            • [^] # Re: Subversion RC-1

              Posté par  . Évalué à 3.

              Ce n'est pas une question de troll mais d'honnèté.
              Tu peux estimer que pour ton usage et ton expérience avec CVS, subversion n'apporte rien et je te crois. Mais si tu considère CVS et Subversion comme des outils avec des caractéristiques, Subversion apporte plein de choses (utile ou non, c'est une autre histoire).

              D'ailleurs il y a plein de gens qui bossent sans utiliser de gestionnaire de version et qui se demandent à quoi ça pourrait leur servir...

            • [^] # Re: Subversion RC-1

              Posté par  . Évalué à 2.

              « Ca n'est pas ma solution mais celle préconisée par les auteurs de CVS; si c'est tu trouves ca nul, tu peux leur dire »

              Ils le savent, les défauts de CVS sont connus et reconnus, mais tout résoudre revient à reprendre tout à zéro. C'est ce que fait l'équipe de Subversion. Quant à CVS il reste très utile, très stable, il est juste important d'en connaître les limitations et de ne pas s'imaginer qu'on peut tout faire avec en bidouillant le repository.

              • [^] # Re: Subversion RC-1

                Posté par  . Évalué à 3.

                Toutafé, d'ailleurs parmis les auteurs du SVN, il y a ... l'un des pères de CVS, donc, les limites de CVS ... hum ... je pense qu'il les connaient bien ;)

        • [^] # Re: Subversion RC-1

          Posté par  . Évalué à 5.

          « deplacement de fichiers, faut pas pousser, ca se fait trés bien, sans "magouille" sur le serveur »

          Ben non. « Sans magouilles » ça veut dire avec des commandes CVS, et sans toucher au repository à la main.
          De plus même avec cette magouille ça marche mal puisque l'historique est cassé là où tu fais cette opération : elle n'est pas mémorisée dans l'historique du projet global.

    • [^] # Re: Subversion RC-1

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

      Euh CVS sait deja faire du renommage/suppression/deplacement
      CVS sait gérer les ajouts, la suppression et la modification de fichiers.

      Pour tout ce qui concerne :
      - les répertoires
      - les déplacements
      - les "renommages" de fichiers ou de répertoires
      CVS ne gère pas d'historique, c'est un problème connu de CVS et qui limite énormément les modifications de structuration du code source. Il faut donc quelque chose d'un minimum abouti pour pouvoir commencer à gérer efficacement les versions.

      Il sait aussi gérer les fichiers binaires
      On peut intégrer des fichiers binaires dans un dépôt CVS, il gèrera l'historique, mais pas les différences. Enfin là, c'est assez logique parce que gérer les différences sur une image ou sur un échantillon de son, ça n'a rien à voir (et c'est assez difficile à définir).

      CVS ne permet pas de faire de facon aisée, ce sont les "reserved checkout"
      Je ne connais pas ce terme, mais il existe avec CVS les possibilités suivantes :
      - notifications d'une modification (via un watch, avec les commandes edit, release et commit)
      - verrouillage d'un fichier (pas terrible à mon sens)

      L'autre problème, c'est que CVS gère l'historique de fichiers de façon indépendante les uns des autres. Impossible d'exprimer qu'une même modification implique plusieurs fichiers.


      Bon, cela dit il me reste à évaluer Subversion et Arch (dont quelqu'un va à coup sûr parler dans les commentaires à suivre).

      • [^] # Re: Subversion RC-1

        Posté par  . Évalué à 10.

        Bon ben je m'y colle ...

        J'ai commence a regarder arch y'a qq temps, et ce qui m'a frappe en premier lieu .. c'est la qualite du tutorial/doc ....
        Ca a l'air simple, c'est oriente changeset, tu peux facilement partager tes archives (http,ftp,sftp) ...

        Y'a l'ajout des signatures/integrite dans les dernieres versions.

        Chaque element du repository a 2 noms: un nom correspondant au path, et un nom interne .. Lors de l'application de modifications, celles-ci sont faites en utilisant le nom "interne" pour designer le fichier .. Du coup si le fichier a ete renomme dans l'archive courante (i.e: son path a change), et bien les modifs seront bien faite sur le fihcier portant le nouveau nom ..

        Les branches ont l'air d'etre simple a faire et a utiliser ...

        Ca me botte assez ....

      • [^] # Re: Subversion RC-1

        Posté par  . Évalué à 1.

        > L'autre problème, c'est que CVS gère l'historique de fichiers de façon indépendante les uns des autres. Impossible d'exprimer qu'une même modification implique plusieurs fichiers.

        Si le commit de tous les fichiers est fait en une fois, on peut considérer que si mais ce n'est pas parfait. A supposer qu'on ne fasse l'update que sur le fichier en conflit (par exemple), on obtient qq chose d'incohérent (qui ne compile pas en général), donc la parade: faire des update intégrals régulièrement avant de compiler/tester/commiter.

        Des outils permettent aussi de retrouver les commit qui ont le même log et des dates proches pour constituer un patch...

    • [^] # Re: Subversion RC-1

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

      > sans compter qu'il gère bien les répertoires (plus généralement
      > les sources possédant une arborescence).

      Oui, mais comment !

      mkdir toto
      cvs add toto

      Ah, tiens, pas besoin de faire de commit ? Ben non, le cvs add fait un mkdir sur le repository, et c'est tout. Bon, déjà, c'est contraire au principe "Une modification locale n'est vue des autres utilisateurs qu'à partir du moment ou elle est commitée".

      Bon, maintenant, on veut supprimer un répertoire. Ben la différence entre un répertoire vide et pas de répertoire du tout en CVS, c'est maigre.

      Maintenant, je veux naviguer dans l'historique de ce répertoire. Tiens, il a été créé quand ? Par qui ?

    • [^] # Re: Subversion RC-1

      Posté par  . Évalué à 3.

      Quand on utilise une gestion de configuration... on n'a pas besoin des "reserved checkout"... que ce soit avec clearcase, CVS ou subversion :

      - Chaque developpeur est censé bosser dans sa branche (avec CVS, ta branche, c'est les fichiers en local sur ton disque).
      - Quand les developpeurs ont terminé leur travail sur leur branche, ils sont cencé merger leur modifications... c'est à ce moment là que les conflits sont gérés...

      Le "reserved checkout" n'est utilisable que sur les petits projets, car il empêche tous les autres develloppeurs de travailler sur le fichier que tu as réservé.

      • [^] # Re: Subversion RC-1

        Posté par  . Évalué à 1.

        Je dirais même plus, la plus importante fonctionnalité de CVS par rapport à RCS (dont il est une sur-couche), c'est justement d'éviter d'avoir à faire des "reserved checkout". Les possibilités de CVS sont à mon sens bien plus pratique.

        Si tu y tiens vraiment, tu peux prendre RCS...

        • [^] # Re: Subversion RC-1

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

          Oula, ca sent le vieux troll.

          "Reserved chckout : pour ou contre" c'est une histoire de gouts/besoins. Inutile de développer plus.

          Pour ma part, je dirais que cela dépends essentiellement de la capacité à faire de 'merge'. Quand on travaille avec des gars qui font de la programmation 'alimentaire' c'est assez rassurant de ne pas avoir à leur confier la responsabilité d'un merge.
          Mais bon, j'avais dit que je dirais rien, alors j'en dis pas plus.

          • [^] # Re: Subversion RC-1

            Posté par  . Évalué à 2.

            Ce n'est pas un troll...
            J'essaye juste d'expliquer pourquoi le "Reserved checkout" n'est pas utile.

            une explication plus complète : http://svnbook.red-bean.com/html-chunk/ch02s02.html(...)

            • [^] # Re: Subversion RC-1

              Posté par  . Évalué à 2.

              Je suis plutôt contre le reserved checkout mais helas il y a des cas où il est indispensable. Par exemple prenons un fichiers binaire (genre une analyse, un schema ou un document OpenOffice, bref une documentation dans un format binaire) et bien si 2 personnes travailles séparément sur la même version fichiers imaginez le boulot que ça va induire lorsque la 2ieme personne voudra commiter. Elle sera obligé de faire un merge à la mano et donc se rappeler de tout ce qu'elle a changé car le logiciel de version ne pourra pas lui indiquer les différences.
              Dans ce cas la seul solution c'est le dialogue. Les personnes succeptibles de travailler sur ces fichiers doivent communiquer pour indiquer lorsqu'elles travaillent dessus.

      • [^] # Re: Subversion RC-1

        Posté par  . Évalué à 3.

        J'ai vu une fois des gens (des bons) bosser sur un projet avec Visual SourceSafe. Et ben, cette histoire de reserved checkout était vraiment handicapant car ils étaient sans arrêt à courir après le gars qui avait oublié de "déverrouiller" le fichier.
        Au final, c'est assez contre-productif à mon gout, d'autant plus que les conflits dans les merge viennent du fait que 2 personnes ont au même moment travaillé sur une même portion de fichier et là, il y a peut être un problème d'organisation.

        • [^] # Re: Subversion RC-1

          Posté par  . Évalué à 1.

          C'est pas possible de limiter le temps de verrouillage ? Et puis plus qu'un reserved checkout, ce qu'il faudrait c'est définir clairement des responsabilités (qui gère quoi, sur quel fichier). Mais ça nécessiterait un peu de synchro humaine et un peu de savoir-vivre et de bon sens, ce qui est souvent beaucoup demander ;)

          • [^] # Re: Subversion RC-1

            Posté par  . Évalué à 1.

            et ça peut être aidé par un outil de gestion du developpement / des bugs, avec des tâches affectées à chaque personne

          • [^] # Re: Subversion RC-1

            Posté par  . Évalué à 1.

            "C'est pas possible de limiter le temps de verrouillage ?"

            Et la durée est en fonction de quoi ?

            Le reserved check-out est une regression. J'ai été "obligé" de travailler avec PVCS (qui est une sombre merde au passage). Je n'ai malheureusement pas compté le temps perdu dans les couloirs et au téléphone pour rappeler aux gens de retirer leurs locks , ni le temps perdu à cause du soft: plantage, lenteur etc...)

            Quand le travail est à peine organisé, la probablité de commiter le même fichier au même instant est faible, la probabilité de commiter une difference sur la même ligne, est extremement faible, et, le cas écheant, les conflits se règlent très facilement dans la très large majorité des cas.

            Pour les fichiers binaires, je ne crois pas qu'ils ont leur place dans un CVS parce que le "C" de cvs c'est justement pour "Concurrent" et que cvs n'a pas pour vocation de gerer des binaires dont il ne sait rien... pas plus que les humains. Enfin bon, y a toujours moyen de versionner des binaires avec cvs.

            Bref (ca n'engage que moi):

            - Gestion des répertoires.

            cool, ca fait d'avantage produit fini que cvs (mais on peut s'en passer ou contourner)

            - Possibilité de renommer et déplacer des fichiers.

            idem.

            - Ajout de méta-données sur les fichiers

            Elles s'integrent avec quoi les méta-données ? Sinon l'historique cvs et les commentaires dans les fichiers ou générés me suffisent largement.

            - Possibilité d'utilisation d'Apache comme serveur et de WebDAV /DeltaV comme protocole.

            Au secours !

            - Optimisation de l'utilisation de la bande passante

            Quoi de plus par rapport à CVS ? (compression/patch)

            - Gestion simplifiée des fichiers binaires

            Bein je trouve pas ca trop compliqué avec cvs:

            http://www.cvshome.org/docs/manual/cvs-1.12.5/cvs_9.html#SEC80(...)

            J'ajoute:

            - les commits atomiques

            C'est un truc marketing ? Tout est commité ou rien n'est commité ? si quelqu'un fait un update/commit pendant un autre commit (atomique) il attend que le commit/rollback soit fini ? Bref l'utilité doit se reveler au moment où 1000 devs travaillent sur le même projet en faisant tous des commits/update "critiques" de façon continu. Je n'ai jamais eu la "chance" de travailler sur ce type de projet :o)

            Bein voilà, s'il y a de vrais avantages à utiliser subversion, je ne crois pas qu'ils soient dans la liste de la news. On va dire que c'est l'ensemble qui fait que subversion est peut être plus interessant que cvs. Bein oui, changer, ca a un coût, c'est un soft recent qui ne s'integre pas à grand chose, et que quasi personne ne connait.

            • [^] # Re: Subversion RC-1

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

              Tout pareil que toi avec PVCS. Dans le problemes marrants, on peut citer un temps de reponse exponentiel en fonction du nombre d'utilisateurs:
              9h du matin: ok, 10s pour se connecter a la base
              10h du matin: ok, 30s pour se connecter a la base
              11h du matin: pas ok, 3 minutes pour se connecter a la base
              3h de l'aprem: pas ok, plantage de la base parce que trop d'utilisateurs connectes en meme temps.

    • [^] # Re: Subversion RC-1

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

      Bon d'accord, je vais corriger...

      Qu'apporte subversion de plus par rapport à CVS ?
      - Gestion de l'historique des modification apportés aux répertoire
      - Possibilité de renommer/déplacer des fichiers en conservant l'historique
      - Copie de fichier avec gestion de l'historique
      - Gestion simplifiée des fichiers binaires (simplifié voulant dire sans config spéciale)
      ...

      Bon c'est vrai que ça a pas l'air immense par rapport à CVS, mais c'est quand même bien pratique...

      Personellement, j'ai utilisé CVS et subversion pour des petits projets plutôt personnels.

      Il faut avoir utilisé subversion pour bien se rendre compte de ce qu'il apporte par rapport à CVS...

      En gros, CVS gère l'historique de fichiers et de leur contenu, Subversion gère l'historique de répertoires et de leur contenu(fichier et contenu des fichiers)... C'est un peu raccourci comme vue, mais à l'utilisation c'est ce qui ressort...

      Bon évidemment, il y en aura toujours pour critiquer dénigrer, ...

      Je n'ai qu'une seule réponse à ceux là: testez et si ça ne vous plait pas, continuez d'utiliser vos outils actuels, ou créez votre propre projet....

      • [^] # Re: Subversion RC-1

        Posté par  . Évalué à 1.

        Mais pourquoi avoir redévellopé un truc plutot que d'avoir ajouté ces optimisations directement dans CVS ????

        • [^] # Re: Subversion RC-1

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

          Ca casserait la compatibilité entre les versions de CVS pour le format d'archivage.

          • [^] # Re: Subversion RC-1

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

            Et surtout, ce ne sont pas des optimisations, mais un chagement complet de la manière de stocke l'info. D'un historique par fichier, tu passe à un historique par dossier...

            Et puis il y a aussi des optimisations pour les transfers de fichiers (passage des diff plutot que des fichiers complets) qui nécessitent une réécriture du protocole de communication entre client et serveur...

            Donc quitte à rendre les clients et serveurs actuels incompatibles, autant tout modifier non ?

        • [^] # Re: Subversion RC-1

          Posté par  . Évalué à 2.

          « Mais pourquoi avoir redévellopé un truc plutot que d'avoir ajouté ces optimisations directement dans CVS ???? »

          Parce que ce ne sont pas juste des optimisations ! Si ça avait été possible avec CVS, je crois que l'équipe de CVS l'aurait fait depuis longtemps. On est vraiment dans un de ces cas où les fonctionnalités voulues nécessitaient une réécriture complète.

      • [^] # Re: Subversion RC-1

        Posté par  . Évalué à 2.

        Subversion apporte aussi:
        - commit atomique (LA fonctionnalité qui manque dans CVS)
        - gestion des branches et des tags extrêmement simple
        - réplication des corrections de bugs entre les branches extrêment simple.
        - renommage/déplacement des fichiers et répertoires avec conservation de l'historique

        • [^] # Re: Subversion RC-1

          Posté par  . Évalué à 2.

          "
          - gestion des branches et des tags extrêmement simple
          - réplication des corrections de bugs entre les branches extrêment simple.
          "

          A mes yeux, cela devrait être dans la liste des avantages de subversion de la news.

          Tu as un lien qui explique comment, par exemple, commiter un bugfix sur plusieurs branches au choix en une seule commande ?

  • # Hors sujet (quoi que)

    Posté par  . Évalué à 2.

    Cette info sur subversion me fait penser a un probleme que je rencontre actuellement avec cvs. Je souhaiterais restreindre l'acces en ecriture de certains sous-repertoires d'une arborescence d'un projet. J'ai fait une recherche rapide sur google et cela n'a pas ete vraiment concluant.

    Cette possibilite existe-t-elle avec cvs? Et avec subversion, cela est-il faisable/plus facile?

    • [^] # Re: Hors sujet (quoi que)

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

      CVS permet de faire des "checkout" en lecture seule. Libre ensuite à l'utilisateur de faire des bêtises ou d'utiliser les services de CVS qui sont là pour cette situation (commande edit et autres).

      Si ce que tu cherches est une gestion de droits d'écriture en fonction de l'utilisateur, je n'ai jamais cherché dans ce sens mais je ne pense pas que ce soit possible avec CVS. Pour Subversion, je laisse les connaisseurs répondre, je serai curieux de savoir :)

    • [^] # Re: Hors sujet (quoi que)

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

      Comme subversion utilise webdav, l'authentification via webdav permet de limiter l'accès à tout que cela soit à un référentiel ou un répertoire de ce référentiel.
      Cf page 90 de la documentation subversion revision 8263

      --------
      C01N C01N

    • [^] # Re: Hors sujet (quoi que)

      Posté par  . Évalué à 1.

      Si tu appliques les droits Unix à tes répertoires du repository (avec des groupes par exemple), tu restreins l'accès à certains sous-répertoires. Avec les ACLs sur ext2/3 c'est encore plus fin mais il faut de toute façon travaillé sur le repository pour faire cela.

      • [^] # Re: Hors sujet (quoi que)

        Posté par  . Évalué à 1.

        CVS nécessite un accès en écriture même pour un simple check-out sans commit (pour les locks).
        Peut-être avec un export? (mais j'ose pas imaginer la situation si tu as besoin de modifier certains répertoires et pas d'autres)

    • [^] # Re: Hors sujet (quoi que)

      Posté par  . Évalué à 3.

      Je souhaiterais restreindre l'acces en ecriture de certains sous-repertoires d'une arborescence d'un projet.

      Tu peux aussi faire ça avec le fichier "commitinfo" qui est dans le sous-répertoire administratif "CVSROOT" (c'est donc $CVSROOT/CVSROOT/commitinfo). Voici le début du fichier :

      # The "commitinfo" file is used to control pre-commit checks.
      # The filter on the right is invoked with the repository and a list of files to check. A non-zero exit of the filter program will cause the commit to be aborted.
      #
      # The first entry on a line is a regular expression which is tested against the directory that the change is being committed to, relative to the $CVSROOT. For the first match that is found, then the remainder of the line is the name of the filter to run.
      # [...]

    • [^] # Re: Hors sujet (quoi que)

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

      Subversion a un module Webdav pour gérer l'authentification assez simplement.

      En gros pour chaque adresse tu peux définir quels utilisateurs et groupes ont les droits d'écritures et quels utilisateurs et groupes ont des droits de lecture.

      Pour restreindre le sous rep /admin à un groupe ou un utilisateur ?

      [/admin]
      @groupelecture = r
      userecriture = rw


      On fait difficilement plus simple

    • [^] # Re: Hors sujet (quoi que)

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

      Va sur les pages de doc CVS de sourceforge, ils te donnent un lien qui permet de creer des utilisateurs et des droits. Le probleme, c'est que en effet, CVS utilise les repertoires courants pour gerer ses locks donc ils doivent etre en ecriture meme pour un checkout read-only.

  • # Re: Subversion RC-1

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

    En tant qu'utilisateur et administrateur de Subversion sur plusieurs projets dans une grosse SSII, voici ce qui me plait dans subversion :
    - facilité de prise en main par l'utilisateur lambda. (La commande line est proche de celle d'unix)
    - le tout réseau intégré par défaut
    - le scripting facile de subversion
    - api python, perl, et C

    Et les outils connexes que j'utilise :
    - cvsweb comme interface web détaillée
    - SVN::Web pour la gestion de l'historique

    Voilà quoi.

    ---------
    C01N C01N

    • [^] # Re: Subversion RC-1

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

      correction : ce n'est pas cvsweb que j'utilise mais ViewCVS
      J'aurais dû prendre mon café....

      ----------
      C01N C01N

      • [^] # Re: Subversion RC-1

        Posté par  . Évalué à 1.

        Subversion est meilleur que CVS surtout sur l'atomicité et le renommage des fichiers. Certes mais il semblerait qu'il est des problèmes à reporter un tel renommage d'une branche à l'autre: cela me semble très limitant.

        http://www.onlamp.com/pub/a/onlamp/2004/01/29/scm_overview.html(...)

        Finallement Subversion n'est pas conçu pour être distribué - CVS non plus mais cette fonctionnalité me semble importante pour des projets OpenSource world-wide... Arch est distribué d'après ce que j'ai lu.

        Bref, le choix est dur. Et finallement en connaissant les défauts de CVS, on s'en accomode très bien.

        • [^] # Re: Subversion RC-1

          Posté par  . Évalué à 5.

          > problèmes à reporter un tel renommage d'une branche à l'autre: cela me semble très limitant.

          et

          > Et finallement en connaissant les défauts de CVS, on s'en accomode très bien.

          Pour Subversion un défaut est "très limitant" ; pour CVS, "on s'en accomode très bien"...

          • [^] # Re: Subversion RC-1

            Posté par  . Évalué à 3.

            En contexte professionel, à supposer que la personne utilise CVS et étudie le passage à Subversion, au moment de justifier le changement, oui : un petit moins de la solution étudiée n'est pas équivalent à un petit moins de la solution utilisée. Le changement a un cout.

            C'est sur que sur le plan purement technique, ca sent le parti pris ;)

  • # Re: Subversion RC-1

    Posté par  . Évalué à 1.

    Depuis que j'utilise Subversion, il me manque un outil pour visualiser des différences entre un fichier chez moi et la version du repository. C'est-à-dire exactement la même chose que "svn diff" mais avec une fenêtre graphique.

    Il en existe des dizaines pour CVS, mais je n'ai pas trouvé pour Subversion...

  • # Re: Subversion RC-1

    Posté par  . Évalué à 1.

    Personellement, j'évalue la valeur d'un logiciel en faisant référence aux nombres de fois où vous vous dites: "Bon, maintenant ça commence à bien faire, il faut que je code un outils à moi !".

    Et il se trouve qu'avec CVS, je me fait souvent (très souvent, même) ce genre de réflexion. Je suis donc heureux que d'autres logiciels arrivent enfin sur le marché.

    Les gros désavantages de CVS sont (à mon humble avis):
    - Une mauvaise gestion du renommage des fichiers
    (perte de l'historique à chaque renommage)

    - Peu ou pas du tout de gestion des répertoires

    - Une execrable gestion des droits sur les fichiers
    (pour ceux qui ont déjà essayé de donner les droits en lecture seule à un groupe d'utilisateurs et en lecture/écriture pour un autre et cela en essayant de ne pas créer de nouveau groupe puisque pas root sur le système...)

    - Une administration qui tourne rapidement au cauchemard

    - Une utilisation compliquée (surtout lorsqu'on doit passer par toute sorte de passwords)

    - .... j'en oublie sûrement...

    Les alternatives qui existent semblent être:
    o CVS (http://www.cvshome.org/(...))
    o Subversion (http://subversion.tigris.org/(...))
    o arch (http://www.gnu.org/software/gnu-arch/(...))
    o Bitkeeper (http://www.bitkeeper.com/(...))
    o autres.... ?

    Quelqu'un a-t-il déjà évalué les différents avantages/inconvénients de chacun de ces systèmes ?

    • [^] # Re: Subversion RC-1

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

      Ben une partie de la réponse est un peu plus haut...

      Pour la gestion renommage des fichiers, répertoires, ... subversion le fait sans problème.

      Pour la gestion des droits d'accès, si tu utilise subversion en réseau avec apache, tu configure les accès via apache => tu peux donc contrôler les droits d'accès aux répertoires pour chaque utilisateur (lecture et ou écriture).

      Pour le reste, c'est plutôt subjectif... à essayer... :)

    • [^] # Re: Subversion RC-1

      Posté par  . Évalué à 5.

      Si ca peut aider :

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

      • [^] # Re: Subversion RC-1

        Posté par  . Évalué à 1.

        Yes ! C'est exactement ce que je cherchais ! Merci !

    • [^] # Re: Subversion RC-1

      Posté par  . Évalué à 2.

      Hum, grâce au résumé que l'on peut trouver sur http://better-scm.berlios.de/comparison/comparison.html,(...) ma conclusion serait:

      Pour des projets importants --> subversion
      Pour de petits projets ou pour ses archives personnelles --> Arch

      En effet, subversion semble être long à installer, vu sa liste de pré-requis (module Apache, Berkeley DB, etc...).

      Ai-je tort ?

      • [^] # Re: Subversion RC-1

        Posté par  . Évalué à 2.

        Un autre lien intéressant:
        http://better-scm.berlios.de/subversion/compelling_alternative.html(...)

        • [^] # Re: Subversion RC-1

          Posté par  . Évalué à 1.

          Autre comparaison (vu par les pro-arch): http://wiki.gnuarch.org/moin.cgi/SubVersionAndCvsComparison(...)

          Est-il vrai que le changelog peut être généré automatiquement (c'est une fonctionalité bien utile!).

          • [^] # Re: Subversion RC-1

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

            http://www.red-bean.com/cvs2cl/(...)

          • [^] # Re: Subversion RC-1

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

            Oui le changelog est généré automatiquement dans Arch (pour peu que tu le veuilles). Pour un exemple (un poil traficoté a coup de sed pour eviter le spam en laissant mon email trainer 50x ds le log) voir:
            http://ed.gomez.free.fr/projects/xvid-devapi4/ChangeLog-devapi4.txt(...)

            Bon il faut savoir que je maintiens cette branche dans une archive Arch tout seul, donc je suis obligé de dire "From truc" pour tracer un peu a qui on doit tel ou tel patch. Mais si les autres dev utilisaient arch , le "qui a fait quoi" serait géré automatiquement, et ferait parti de l'historique. Voir un mail assez recent sur xvid-devel:
            http://article.gmane.org/gmane.comp.video.xvid.devel/3757(...)

            Trois branches, la mienne ne servant qu'a l'integration du travail des 2 dev PPC.

            NB: les logs automatiques sont generes par "branche".

          • [^] # Re: Subversion RC-1

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

            Ben dans subversion oui, un petit "svn log > ChangeLog" et c'est fait...

            Bon c'est pas nécessairemet le format de changelog qui est utilisé un peu partout, mais c'est juste cosmétique... :)

            Un petit exemple ci-dessous:


            ------------------------------------------------------------------------
            rev 137: olivier | 2003-02-05 00:58:35 +0100 (mer, 05 fév 2003) | 3 lines
            Changed paths:
            M /yafi/NEWS
            M /yafi/TODO
            M /yafi/configure.ac
            M /yafi/python/analyser.c
            M /yafi/scripts/sources/yafi-latex

            Removed a compilation bug.
            Changed release version to 0.3.1

            ------------------------------------------------------------------------
            rev 136: olivier | 2003-02-03 02:28:28 +0100 (lun, 03 fév 2003) | 1 line
            Changed paths:
            M /yafi/README

            • [^] # Re: Subversion RC-1

              Posté par  . Évalué à 1.

              Pour la comsmétique :
              svn log -xml > log.xml
              Ensuite il ne reste qu'à écrire un fichier XSL (ou en reprendre un d'internet il en existe déjà) et à le passer dans un processeur XSLT (sablotron par exemple) et voilà un changelog tout beau tout bien présenté.

      • [^] # Re: Subversion RC-1

        Posté par  . Évalué à 2.

        > En effet, subversion semble être long à installer

        Pour la partie client c'est très rapide et on trouve facilement des paquets.
        Pour la partie serveur ça rapide maintenant (ça dépend de ta distribution) :
        http://subversion.tigris.org/project_packages.html(...)

        Ya des dépots apt pour debian, yum pour redhat ...

        Pour les prérequit, ça devient petit à petit du standard. Pour fedora, il faut ajouter apr (qui est déjà livré mais la version doit être trop ancienne) et neon.
        Donc dans un proche avenir, pour avoir subversion (client et serveur) il faudra ajouter neon par rapport à une distribution standard.

      • [^] # Arch vs. les autres (etait: Re: Subversion RC-1)

        Posté par  . Évalué à 5.

        Je suis en train de tester GNU Arch sur deux projets libres (Axiom, un gros projet, et DemExp, un petit projet). J'ai à peine eu le temps de me faire la main sur les branches et pas encore eu le temps de tester les merges, mais pour l'instant, Arch me plait vraiment.

        Pour moi, les gros avantages de Arch (dans le désordre):

        - commit atomic avec des changset => si on l'utilise correctement, chaque commit correspond à un changement du système (correction de bug, nouvelle fonctionnalité, ...)

        - fonctionnement en mode décentralisé. Pas besoin de serveur. Si on a une page web, on peut mettre un mirroir de son archive disponible en FTP/HTTP/WebDAV que les autres peuvent récupérer. C'est typiquement le fonctionnement des projets libres

        - activement développé. Réponses rapides sur la mailing list gnu-arch-users.

        - logiciel libre



        Cela dit, je n' ai pas testé sur de gros projets ou avec des branches multiples. Donc impression à revoir dans quelques temps.

        Pour ceux qui voudraient utiliser Arch, jeter un coup d'oeil sur son Wiki, c'est bourré d'infos utiles.

  • # killer feature

    Posté par  . Évalué à 5.

    Un enorme avantage pour Subversion :

    Il permet de passer les firewalls car il utilise le protocole http (WebDAV) et permet donc d'acceder à une archive de partout !

    • [^] # Re: killer feature

      Posté par  . Évalué à 2.

      Et ce n'est pas négligeable !!!!

    • [^] # Re: killer feature

      Posté par  . Évalué à 1.

      Ça c'est un truc qui doit plaire aux admins :)

    • [^] # Re: killer feature

      Posté par  . Évalué à 2.

      Plus précisément, subversion dispose de plusieurs moyens d'accèder à un répository:
      • directement sur les fichiers ;
      • par http/https (WebDAV) ;
      • par un protocole propriétaire directement ou via ssh, pour ce dernier point c'est le client subversion qui se débrouille tout seul avec ssh, pas du tunnelling TCP/IP.

    • [^] # Re: killer feature

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

      Ouais. Et une enorme avantage de CVS: a partir du moment ou tu as un serveur ssh, tu as tout ce qu'il faut pour installer un serveur CVS. Pour subversion, il faut installer apache + webdav, ce qui est quand meme largement plus lourd!

Suivre le flux des commentaires

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