Sortie de Subversion 1.0.0

Posté par  . Modéré par Nÿco.
Étiquettes :
0
24
fév.
2004
Gestion de versions
Le logiciel de gestion de version, Subversion, vient de sortir en version stable. Il contient de nombreuses améliorations par rapport à CVS. Cette version constitue un aboutissement après 3 ans de travail pour l'équipe de développement, et en particulier pour Karl Fogel, l'auteur principal de Subversion et de CVS. Félicitations aux développeurs et à la société CollabNet, qui a embauché l'équipe de développement pour mener à bien ce projet. Subversion apporte des nouveautés intéressantes par rapport à CVS :
- gestion en version des répertoires,
- possibilité de renommer un fichier dans le référentiel ou de le déplacer,
- gestion atomique des transactions,
- gestion simplifiée des branches,
- gestion optimisée des fichiers binaires,
- mise à disposition d'une API permettant d'envisager des clients graphiques de haut niveau, des outils d'administration, ...,
- ajout de méta-données sur les fichiers,
- optimisation de l'utilisation de la bande passante,
- possibilité d'utiliser Apache 2 au niveau du serveur, ce qui laisse entrevoir de nombreuses possibilités (gestion des utilisateurs, pas de problème de pare-feu)
- ...

Il existe déjà des nombreux clients graphiques de qualité :
- TortoiseSVN pour Windows,
- Subclipse pour eclipse,
- AnkhSVN pour Visual Studio .NET,
- RapidSVN (client multi-plateforme),
- Sven pour Mac OS X,
- WebSVN pour une consultation web améliorée.

Subversion n'est pas le seul outil dans sa catégorie. Il existe d'autres alternatives opensource comme Arch (http://www.gnu.org/software/gnu-arch). Il constitue cependant une suite logique à CVS (la majorité des lignes de commande comportent les mêmes options), il est très stable et très agréable à utiliser.

Aller plus loin

  • # Re: Sortie de Subversion 1.0.0

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

    Avec les paquets de debian unstable mes derniers tests sont passés comme une lettre à la poste. Subversion va très rapidement remplacer CVS pour ma part.

  • # [HS] Arch

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

    Comment fait-on pour créer des versions (releases) sur Arch sachant qu'il n'y a pas de référentiel centralisé ? Est-ce que cela veut dire que quiconque peut faire une release de sa propre archive ?

    • [^] # Re: [HS] Arch

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

      Dit autrement :

      Comment fait-on pour créer des versions (releases) sur Linux sachant qu'il n'y a pas de référentiel centralisé ? Est-ce que cela veut dire que quiconque peut faire une release de son propre Linux ?

      C'est fou ce que CVS (et donc Subversion) ont pu formatter la manière dont les gens concoivent le développement open source : s'il n'y a pas un serveur central (avec tout ce que cela implique de difficulté à obtenir un accès, de fork quand le serveur est en rade ou son admin faché avec le reste de l'équipe), les gens ont l'air tout perdu.

      Avant CVS, on se débrouillait avec diff+tar+gzip+patch, n'importe qui pouvait publier sa version, et ça n'était pas plus mal (au niveau liberté de distribution et de forkage). Ça n'empêchait pas qu'il y ait une version maître, mais sa seule différence avec les autres était une différence politique (c'est moi le boss, c'est ma version qui compte - en général parce que c'est moi qui ait créé le logiciel, ou qui suis le plus apte à sortir des versions acceptables) plus que technique (c'est moi qui gère les logins sur le serveur CVS).

      En fait, CVS/Subversion c'est la cathédrale, alors que Arch c'est le bazar.

      • [^] # Re: [HS] Arch

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

        On peut parler technique ???

        Avant CVS, on se débrouillait avec diff+tar+gzip+patch
        Et encore avant, on recopiait le programme à la main

        ça n'était pas plus mal (au niveau liberté de distribution et de forkage)
        Et ça donnait, sur les forums, des trucs du style :"
        - j'arrive pas à compiler bidule
        - t'as quelle version ?
        - la 0.12
        - ouais mais quel auteur ? T'as les patchs TrucMuche ?"

        J'avoue que cela me manque énormément aujourd'hui.

        Ça n'empêchait pas qu'il y ait une version maître, mais sa seule différence avec les autres était une différence politique (c'est moi le boss, c'est ma version qui compte - en général parce que c'est moi qui ait créé le logiciel, ou qui suis le plus apte à sortir des versions acceptables) plus que technique (c'est moi qui gère les logins sur le serveur CVS).
        Ce n'est certainement pas ton logiciel de gestion de version qui t'empêche de forker. Dans un projet, l'aspect humain est beaucoup plus important que l'aspect technique. Et là, je me rend compte que tu vois Arch comme étant un outil favorisant l'absence de communication humaine ("Si tu m'emmerdes, je fais ma propre version dans mon coin car Arch me le permet").

        En fait, CVS/Subversion c'est la cathédrale, alors que Arch c'est le bazar.
        Tiens, cela rejoint d'ailleurs ta première assertion. Linux (le noyau), c'est la cathédrale et Arch, c'est beau, c'est le bazar, c'est ... (complèter avec un nom de projet utilisant Arch).

        • [^] # Re: [HS] Arch

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

          -- ouais mais quel auteur ? T'as les patchs TrucMuche ?"
          J'avoue que cela me manque énormément aujourd'hui.

          Ça n'a pas du tout disparu : patches utilisateurs pour FreeS/WAN par exemple, il y en avait aussi pour OpenSSL à un moment je crois.

          je me rend compte que tu vois Arch comme étant un outil favorisant l'absence de communication humaine

          Mais absolument pas, je ne vois pas où tu as pu lire ça. Je pense que Arch permet à quelqu'un de continuer à travailler sur un projet quand des problèmes de communication humaine se posent, à partager son travail de manière utile et efficace dans ces cas là. C'est aussi valable quand le projet tourne bien : le gestionnaire du projet n'a pas à se prendre la tête à donner des accès CVS au compte-goutte sur le serveur ultra-sécurisé du projet, il peut facilement intégrer les patchsets envoyés par les contributeurs, même ceux qu'il ne connaît pas encore bien et en qui il n'a pas, par défaut, confiance.

          Tiens, cela rejoint d'ailleurs ta première assertion. Linux (le noyau), c'est la cathédrale et Arch, c'est beau, c'est le bazar

          Mais je n'ai pas écrit ça du tout ! Je ne sais pas lequel de nous deux est mal réveillé, mais on n'est pas sur la même fréquence on dirait. Je m'aperçois au passage que j'ai mal rédigé la paraphrase qui commence mon message. Mon but était de faire comprendre au posteur initial que sa question (mais alors avec arch c'est le boxon ?) se posait tout autant au noyau Linux (il y a plusieurs personnes qui publient leur version de Linux -- ac dans le passé, mm actuellement, sans compter Linus bien sûr ; il n'y a pas un CVS/Subversion/BitKeeper qui centralise tout), et que pourtant le noyau Linux s'en sortait très bien. BitKeeper tout comme Arch fonctionne par distribution de patchsets (enfin je crois, BitKeeper j'ai jamais essayé), ça fait toute la différence.

          • [^] # Re: [HS] Arch

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

            Mais absolument pas, je ne vois pas où tu as pu lire ça. Je pense que Arch permet à quelqu'un de continuer à travailler sur un projet quand des problèmes de communication humaine se posent, à partager son travail de manière utile et efficace dans ces cas là.
            Okay, je comprends bien que le forkeur n'a pas à recréer son propre référentiel de gestion de version.

            C'est aussi valable quand le projet tourne bien : le gestionnaire du projet n'a pas à se prendre la tête à donner des accès CVS au compte-goutte sur le serveur ultra-sécurisé du projet, il peut facilement intégrer les patchsets envoyés par les contributeurs, même ceux qu'il ne connaît pas encore bien et en qui il n'a pas, par défaut, confiance.
            Encore vrai, mais tout cela est plus une question d'organisation qu'autre chose. Avec svn, la distribution d'un gros patch peut se faire aussi très facilement (bon, je ne veux pas lancer de troll soyons clairs). D'ailleurs, dans ton histoire, le gestionnaire du projet ne donne pas d'accès CVS au compte-goutte mais il centralise les patches et ça devient une cathédrale.

            Mais je n'ai pas écrit ça du tout ! Je ne sais pas lequel de nous deux est mal réveillé, mais on n'est pas sur la même fréquence on dirait.
            C'est moi qui suis mal réveillé ;-)

            Mon but était de faire comprendre au posteur initial que sa question (mais alors avec arch c'est le boxon ?) se posait tout autant au noyau Linux
            D'ailleurs le posteur initial, c'était moi et je posais juste une question purement technique. Je n'ai jamais dit qu'Arch c'était le boxon. Il s'agit d'une façon de travailler plus originale que les logiciels classiques.

            et que pourtant le noyau Linux s'en sortait très bien.
            Tout à fait d'accord mais l'équipe du noyau fait de plus en plus de la cathédrale me semble-t-il, au moins lors de la sortie des versions stables.

            BitKeeper tout comme Arch fonctionne par distribution de patchsets
            Beaucoup de logiciels de gestion de conf font comme ça car cela permet de limiter la bande passante quand le mécanisme est centralisé. CVS le fait lui pour chaque fichier car il repose sur RCS qui gère des fichiers et non des arbres de fichiers. Clearcase fonctionne aussi comme CVS en vue snapshot.

      • [^] # Re: [HS] Arch

        Posté par  . Évalué à 5.

        Y a aussi moyen de faire un truc centralisé avec arch, c'est à dire une archive "maître" dans laquelle plusieurs personnes peuvent effectuer des changements, ce qui donne un fonctionnement à la cvs/subversion. Mais même quand ce système est utilisé, le fonctionnement en mode décentralisé est toujours possible.

        • [^] # Re: [HS] Arch

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

          Bon, pour info, en me rebaladant sur le site de Subversion, j'ai vu que l'on pouvait faire du décentralisé avec svk. Il semblerait que cela utilise une couche en Perl (je commence à ressembler à Guillaume Durand pendant War In The Golf I ou à Olivier Mazerolle ;-).

  • # Re: Sortie de Subversion 1.0.0

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

    Et un lien avec un comparatif des SCM (passe sur linuxfr il y a peu, mais de bonne facture, donc c'est toujours utile) :

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

    Voila voila.

  • # Re: Sortie de Subversion 1.0.0

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

    Est ce que les hebergeurs de projet libre comme savanah envisage de le mettre en place?

    • [^] # Re: Sortie de Subversion 1.0.0

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

      Manifestement ça fait plusieurs mois (voire années) que des gens viennent sur la mailing-list des hackers Savannah poser cette question. Voici ce que l'on peut retirer des (courtes) discussions qui ont suivi :

      * Savannah n'est pas « mariée avec CVS », ses admins sont tout à fait ouvert à l'installation de plusieurs systèmes de gestion de sources sur Savannah.
      * Les admins sont débordés, et ont mieux à faire que de passer du temps à comprendre, tester et installer Arch ou Subversion sur Savannah.
      * Toute aide dans la catégorie « pré-mâchage du travail » est la bienvenue.
      * Comme les admins sont débordés, c'est pas facile de travailler avec eux et donc de les aider.
      * Les admins n'installent sur Savannah que des packages en provenance de Debian stable.
      * Les admins ne veulent pas installer deux versions d'Apache sur Savannah, qui pour l'instant tourne sous Apache 1.3.xx.
      * Les admins n'ont pas confiance en Apache 2.x, dont Subversion a besoin (ça date de 2002 ou 2003, leur opinion a peut-être évolué depuis).
      * Les logiciels nécessaires au fonctionnement de Arch (sftp notamment) sont installés et en état de marche.
      * Aux dernières nouvelles sur la mailing-list de Arch, il y a encore des détails qui coincent.

      Voilà, je crois que j'ai fait le tour. Je précise pour ceux feraient quelques recherches à ce sujet de ne pas s'étonner de certains résultats : subversions.gnu.org est l'ancien nom de savannah.gnu.org.

      Au fait, vu les récentes attaques sur les dépôts open-source, Richard Stallman aimerait que les gestionnaires de sources assurent l'authentification et l'intégrité des contributions. Arch le fera en version 1.2, pour Subversion je ne sais pas où ça en est (avec des hooks ça doit le faire, non ?).

      • [^] # Re: Sortie de Subversion 1.0.0

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

        pour Subversion je ne sais pas où ça en est (avec des hooks ça doit le faire, non ?).
        Oui, sans trop de pb. J'avais déjà essayé avec CVS et le problème était que l'on ne pouvait par retirer la signature GnuPG des logs. Avec subversion, mon script devrait marcher puisque svnadmin permet de retoucher le log à n'importe quel moment.

        • [^] # Re: Sortie de Subversion 1.0.0

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

          Tiens, d'ailleurs si cela intéresse quelqu'un, voilà le code pourri en perl (désolé, c'est pas mon langage habituel) que j'avais pondu (il y a forcément plus simple, on peut le faire avec gpgme etc...):

          
#!/usr/bin/perl -w
          
use Text::ParseWords;
          

          
use strict;
          

          
my $retour = 1;
          

          
#We load into a hash the email address from the correspondance table
          
my %hash;
          
open(FILE,"< emailTable.csv") || die "enable to load the correspondance table";
          
while ()
          
{
          
    my @record=&quotewords(';',0,$_);
          
    $hash{$record[0]}=$record[1];
          
}
          

          
my $emailAddress = "";
          
#We cut to get the e-mail address
          
my $filename = $ARGV[1];
          
open(GPG,"gpg --logger-fd 1 --verify $filename |grep Good | cut -d '\<' -f2 | cut -d '\>' -f1 | ") || die "can't fork";
          
#If the signature is good, we got the address
          
while ($emailAddress = )
          
{
          
    chomp($emailAddress);
          
    chomp($hash{$emailAddress});
          
  
          
    if ( $ARGV[0] eq $hash{$emailAddress} )
          
    {
          
	print "Signature okay!!\n";
          
	$retour = 0;
          
    }
          
}
          
close(GPG);
          

          
exit($retour);


          Le fichier emailTable.csv contenant les correspondances entre adresses email et non d'utilisateur CVS (ou Subversion du coup). Le script prend en paramètre le log signé et le nom de l'utilisateur qui a commité. On vérifie alors la signature et autorise ou non le commit. La faiblesse sous CVS du truc venait donc du fait qu'un pirate ayant le login CVS et l'adresse e-mail n'avait qu'à relire un log existant dans le référentiel et rajouter son texte hors balise GnuPG. Dans ce cas, le texte est vu comme correctement signé. D'ailleurs, si vous passez un texte signé correctement à GnuPG mais avec du texte hors balise, l'ensemble sera considéré comme signé, ce qui me semble être une faille dans la signature.

          • [^] # Re: Sortie de Subversion 1.0.0

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

            D'ailleurs, si vous passez un texte signé correctement à GnuPG mais avec du texte hors balise, l'ensemble sera considéré comme signé, ce qui me semble être une faille dans la signature.

            Je me souviens que ce genre de problème s'est posé sur la mailing-list d'Arch aussi. Je crois qu'il y a trois solutions à ce problème :

            * Faire une signature extérieure. Problèmes : doublement du nombre de fichiers ; pas forcément possible si on veut plusieurs signatures dans un seul fichier.
            * Gérer (virer) le texte externe avant de passer le reste à GnuPG. Problème : il faut écrire son propre parser de texte signé (alors que forcément, GnuPG en a déjà un) et il faut supporter les variations et éventuelles évolutions du format. Et puis plus de code égale plus de bugs.
            * Ajouter une option à GnuPG pour qu'il signale la présence de texte externe. Problème : il faut écrire l'option et convaincre les auteurs de GnuPG (et attendre la prochaine version).

            • [^] # Re: Sortie de Subversion 1.0.0

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

              * Gérer (virer) le texte externe avant de passer le reste à GnuPG. Problème : il faut écrire son propre parser de texte signé (alors que forcément, GnuPG en a déjà un) et il faut supporter les variations et éventuelles évolutions du format. Et puis plus de code égale plus de bugs.
              C'est ce que je comptait faire à terme mais c'est lourdingue.

              * Ajouter une option à GnuPG pour qu'il signale la présence de texte externe. Problème : il faut écrire l'option et convaincre les auteurs de GnuPG (et attendre la prochaine version).
              Et encore, signaler la présence du texte externe est vraiment très gentil pour un outil de sécurité. Un texte soit-disant signé ne devrait pas être considéré comme correctement signé s'il contient quelque chose en dehors des balises. Enfin, c'est mon avis.

              • [^] # Re: Sortie de Subversion 1.0.0

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

                Oui mais alors, comment signer un email (qui sera modifié par les serveurs par lesquels il passera) ? Comme stocker plusieurs textes signés dans un seul fichier ? Le coeur du problème, c'est que GnuPG te garantit que le texte à l'intérieur des délimiteurs est correct, pas que l'ensemble du fichier texte l'est. Il faut clairement une option pour ça. Mais ce n'est pas facile : comment gérer d'éventuelles lignes vides ou espaces ajoutés avant ou après ? On a envie de les ignorer, mais il ne faut pas...

      • [^] # Re: Sortie de Subversion 1.0.0

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

        > Apache 2.x, dont Subversion a besoin

        Subversion n'a besoin d'Apache2 que dans sa version Webdav. Tu peux aussi l'utiliser avec ssh si tu veux.

        • [^] # Re: Sortie de Subversion 1.0.0

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

          Oui, mais si on veut que de simples utilisateurs puissent récupérer une branche, comment fait-on ? On ne peut pas vraiment créer un compte SSH par téléchargeur potentiel, et encore moins créer un compte SSH « anonyme », non ? Alors quoi ? Un serveur HTTP sans WebDAV peut-il suffire, ou un serveur FTP ?

      • [^] # Re: Sortie de Subversion 1.0.0

        Posté par  . Évalué à 4.

        Pour arch, y a pas vraiment besoin d'installer des trucs, pour ma part je publie des archives arch via ftp sur free. Mais effectivement un accés direct en sftp est quand meme plus propre, ca doit aussi éviter d'avoir une archive en locale que l'on mirrore via ftp sur les pages persos free.
        T'aurais plus d'infos sur les "détails qui coincent" pour arch et savannah ?

        • [^] # Re: Sortie de Subversion 1.0.0

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

          Non (ça date je dirais de septembre/octobre dernier), mais ça semblait très mineur. Mais comme les admins n'ont pas le temps, ça n'a pas (encore) été corrigé manifestement.

          • [^] # Re: Sortie de Subversion 1.0.0

            Posté par  . Évalué à 1.

            Ok, faudrait que je cherche un peu pour retrouver les posts en question, je connais qqu'un qui maitrise bien arch et y aurait peut être moyen de le convaincre de filer un coup de main...

      • [^] # Re: Sortie de Subversion 1.0.0

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

        Il n'y a jamais eu de discution par rapport à la licence de subversion ?

        Sur leur site:

        License: CollabNet/Tigris.org Apache-style license
        This license is the same as the Apache Software Foundation license, but with
        CollabNet given as the copyright holder.


        Est compatible GNU/GPL ?

    • [^] # Re: Sortie de Subversion 1.0.0

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

      Ça existe depuis déjà quelque temps sur alioth.debian.org.

    • [^] # Re: Sortie de Subversion 1.0.0

      Posté par  . Évalué à 3.

      Gna! planifie un support de subversion à l'avenir, probablement lorsque ce sera dans Debian stable. N'importe qui interessé par le support de subversion peut proposer sa participation pour offrir son support.

      https://gna.org(...)

  • # Question technique

    Posté par  . Évalué à 1.

    bonjour à tous

    je n'ai jamais utilisé cvs ni subversion ni arch
    je n'arrive pas à comprendre exactement comment tout cela marche.
    Exemple: 2 personnes travaillent sur le même fichier. Ils font donc chacun un "checkout" du fichier, pour le télécharger sur leur machine.
    Ils l'éditent et font des modifs, dans 2 endroits bien différents du fichier

    ensuite chacun fait un "commit"
    ça marche ? le fichier sur le serveur est-il le résultat des 2 modifications ?

    maintenant ça se corse : les 2 personnes, qui ont du mal à communiquer, bossent sur la même partie du fichier. Le premier "commit" doit bien se passer, mais comment se passe le suivant ?

    • [^] # Re: Question technique

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

      Sur 2 endroits bien différents, il me semble que cvs gère pas trop mal la chose. Sur une endroit similiaire, il va te dire "Je ne veux pas, je te donne la main debrouille-toi". En fait, cvs utilise diff.

      Une fonctionnalité intéressante serait (suivant le type de source) d'avoir un verrou sur une fonction, un if, un while.

      • [^] # Re: Question technique

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

        Le reserved checkout est possible mais pas encouragé par CVS (et je suppose Subversion). Il existe une solution à mi-chemin entre le unreserved checkout (fonctionnement normal de CVS) et le reserved checkout (verrous) : la fonctionnalité de watch associé à edit, unedit et watchers.

        cvs watch [on|off|add|remove]
        cvs watchers
        cvs edit
        cvs unedit

      • [^] # Re: Question technique

        Posté par  . Évalué à 3.

        CVS et tous les outils de la sortent gerent cela correctement d'un point de vue technique.
        Mais il ne faut pas oublier non plus que si je supprime une declaration d'une variable inutilisee en haut et que qq d'autre se met a l'utiliser en bas, les 2 commit vont se passer sans aucun probleme. Mais le code resultant ne va plus compiler !
        Et ce n'est qu'un exemple parmi tant d'autres

        Le bonjour chez vous,
        Yves

        • [^] # Re: Question technique

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

          Mais seul un malade committerait du code sans le recompiler juste avant.

          • [^] # Re: Question technique

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

            Je dois être dans un hopital alors...

            • [^] # Re: Question technique

              Posté par  . Évalué à 1.

              Je dois être dans un hopital alors...
              Certainement ... quand tu fait ca dans dans notre groupe de projet, ils t'arrachent un doigt a chaque fois...

              :D

              • [^] # Re: Question technique

                Posté par  . Évalué à 1.

                Et c'est pas facile de taper avec le nez sur un clavier ;)

                • [^] # Re: Question technique

                  Posté par  . Évalué à 1.

                  C'est pour ca qu'on a cree la reconnaissance vocale

                  • [^] # Re: Question technique

                    Posté par  . Évalué à 1.

                    mais il faut commencer tout de suite avec. Si tu t'es déjà explosé le nez sur le clavier, t'as une voix trop nazillarde.

          • [^] # Re: Question technique

            Posté par  . Évalué à 1.

            Ce n'est pas le problème, ton code compile peut-être tel quel, mais pour le mélange de ton code à celui d'un autre sans coordination entre vous deux il n'y a aucune garantie.

            • [^] # Re: Question technique

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

              D'où l'intérêt des compilations automatiques (de nuit par exemple)...

            • [^] # Re: Question technique

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

              Je ne suis pas d'accord avec toi. Si tu as une bonne methodologie de developpement, il n'y a aucun probleme, malgre l'absence de synchronisation explicite.

              Si tu travailles proprement, tu maintiens une copie locale par jeu de mofidication que tu veux apporter. Dans chacune de tes copies locales, tu as ta modif en cours. Lorsqu'elle est prete (et testee), tu fais une mise a jour pour recuperer la derniere version du soft, tu relances tes tests pour verifier que qq'un n'a pas pete qqch dans ton dos, tu corriges les conflits si par hasard (et c'est rare) qq'un a bosse sur les memes fichiers que toi, tu relances tes tests une fois de plus et tu commites l'ame en paix.

              Pour faire bien, tu as aussi une copie locale sans aucune modification a cote. Juste apres ton commit, tu fait une mise a jour sur cette copie, et tu recompiles tout pour verifier que tu n'as pas oublie des morceaux. Tu relances tes tests une derniere fois et tu peux te reposer avec la satisfaction du devoir accompli.

              Donc malgre un melange sans aucune coordination, il n'y a aucun probleme et toutes les garanties que tout se passe bien.

              Je bosse comme ca avec plein de developpeurs sur plein de projets et ca ne pose aucun probleme.

              Le seul cas qui pourrait etre mechant, c'est si deux personnes codent en meme temps la meme foncitonalite. Mais en pratique, c'est tres tres rare, chacun a ses preferences et un minimum de communication suffit.

    • [^] # Re: Question technique

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

      Avant de commiter un fichier édité dans sa propre sandbox, il faut faire un cvs update pour voir si le fichier a été modifié/commité par quelqu'un, et résoudre les conflits le cas échéant.

      Les commits ne se font jamais au même moment, donc si le même passage est modifié sur le même fichier par deux users, alors le premier passe sans problème, le deuxième doit résoudre le conflit : soit en abandonnant ses modifs, soit en reprenant les modifs précédemment commitées, soit en branchant (moyen).

      • [^] # Re: Question technique

        Posté par  . Évalué à 1.

        donc la "fusion" des modifications se fait au niveau du client et non pas du serveur

        remarque, moi qui bosse sur sourcesafe, qui fait ça au niveau du serveur, j'avoue que pour plus de sécurité je fais très souvent les fusions en local avant de commiter ensuite.

        • [^] # Re: Question technique

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

          De fait, le developpeur sait mieux que le serveur comment il doit fusionner le code en conflit.

          En lisant la premiere fois le fonctionnement de CVS, je me suis aussi dit que ce serait mieux si il resolvait les conflits automatiquement. Mais quand je suis arrive au cas pratiques, j'ai beni CVS de laisser le developpeur resoudre le conflit manuellement. Car seul le developpeur peut vraiment comprendre ce qui se passe derriere un conflit.

    • [^] # Re: Question technique

      Posté par  . Évalué à 2.

      « maintenant ça se corse : les 2 personnes, qui ont du mal à communiquer, bossent sur la même partie du fichier. Le premier "commit" doit bien se passer, mais comment se passe le suivant ? »

      En effet le premier se passe bien. Avant de commiter le second doit mettre à jour, et c'est là que les conflits vont apparaître. Grosso modo, au lieu d'une mise à jour qui modifie les fichiers locaux d'après le repository, on trouvera dans le fichier des choses comme :

      -------- conflit détecté
      ici le code présent dans le repository
      ==========
      ici le code que le développeur voulait commiter (ou l'inverse)
      ---------- fin du conflit

      Le développeur doit faire la fusion entre les deux manuellement, ensuite il peut commiter.

  • # Re: Sortie de Subversion 1.0.0

    Posté par  . Évalué à 1.

    Juste une petite question , il n'y a pas de portage vers AIX et HP-UX officiel ?

    dans la section download , je ne vois que les sources à recompiler alors que CVS gère trés bien ces machines .

  • # Donc qu'est-ce qu'il vaut mieux utiliser ?

    Posté par  . Évalué à 1.

    Je sais que ce fil est normalement dédié à subversion mais pour avoir utilisé CVS/RCS, subversion et dernièrement Arch, je me demande toujours lequel convient le mieux.

    En fait je me demande quelle solution adoptée pour _tous_ mes projets qu'ils soient petits ou grands.

    Arch m'a bien séduit avec son mode de fonctionnement et l'ajout récent d'une fonctionnalité importante à mes yeux (l'authentification) mais je suis encore très attaché à CVS. Subversion quant à lui me laisse dubitatif sur sa façon de fonctionner.

    Quel est LE gestionnaire de versions du futur ? Arch est un projet ambitieux et bien avancé (quoique un tantinet plus compliqué à utiliser). De plus il fait partie du projet GNU. Donc logiquement j'aurais tendance à m'orienter vers lui et donc à migrer définitivement vers Arch. Mais j'aimerais d'un autre côté donner une nouvelle chance à subversion qui ne m'avait pas trop convaincu à l'époque.

    J'ai besoin de vos lumières parce que les comparatifs c'est bin joli mais rien ne remplace un bon vieil échange/retour d'expérience.

    • [^] # Re: Donc qu'est-ce qu'il vaut mieux utiliser ?

      Posté par  . Évalué à 1.

      La question c'est pas "quel est le mieux ?", mais "quel est celui qui te convient le mieux ?"
      A mon avis arch et subversion ont chacun leurs avantages et leurs inconvénients. Personnellement, j'aime beaucoup arch, donc j'aurais tendance à te le recommander, mais je n'ai jamais testé subversion, donc mon avis ne vaut pas grand chose :) Mais arch a quand meme ses inconvenients, essentiellement que c'est quand meme assez complexe à utiliser/mettre en place.
      Donc je te conseille de tester les deux (arch et subversion), et de choisir celui qui te séduit le plus.

      • [^] # Re: Donc qu'est-ce qu'il vaut mieux utiliser ?

        Posté par  . Évalué à 2.

        Arch m'a plus que séduit malgrès la mise en place assez complexe (dailleurs il faut tirer un gros chapeau au mainteneur du wiki).

        Une autre difficulté avec Arch est que lorsque on a pensé "CVS" pendant X années, c'est dur de changer tout d'un coup la façon de voir les choses.

        Et dernier inconvénient majeur, le support dans Emacs est balbutiant puisque le VC pense en terme de fichiers et non pas en terme de patchset. Enfin c'est pas ce qu'il y a de plus grave non plus mais quand même ça peut bloquer des personnes :)

    • [^] # Re: Donc qu'est-ce qu'il vaut mieux utiliser ?

      Posté par  . Évalué à 1.

      Il existe pour moi 2 grandes différences :

      - Arch est un outil qui comporte des concepts novateurs, mais qui est actuellement encore en phase de R&D. Subversion est un produit stable, très professionnel et qui comporte de nombreux clients graphiques.

      - Subversion fonctionne sur le concept d'un référentiel centralisé et Arch sur le principe de synchronisation de référentiels décentralisés. Pour une utilisation au quotidien dans un monde professionnel, Subversion me semble beaucoup plus adapté.

      En ce qui me concerne, il n'y a pas photo : je préfère largement Subversion.

      • [^] # Re: Donc qu'est-ce qu'il vaut mieux utiliser ?

        Posté par  . Évalué à 2.

        En ce qui concerne le deuxième point, comme je l'ai déjà dit, il est tout à fait possible de mettre en place un référentiel centralisé avec Arch. Le développement de rhythmbox fonctionne sur ce principe, plusieurs développeurs peuvent inclure leurs changements dans le référentiel principal, l'authentification et la transmission se faisant via ssh et des clés publiques. De plus, chaque changement est signé avec la clé gpg du développeur.

        En ce qui concerne la phase de R&D de arch, c'est vrai qu'il évolue encore très vite (quoi que les fonctionnalités de base semblent se stabiliser au fur et à mesure que tla 1.2 approche), et que ça peut être assez pénible à suivre.

      • [^] # Re: Donc qu'est-ce qu'il vaut mieux utiliser ?

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

        Oui mais :

        - Subversion n'est pas forcément très stable (corruption de la base de données, rare mais possible), il est lui aussi assez jeune. Arch n'utilise au final que tar+gzip pour stocker les fichiers, ce qui facilite un éventuel sauvetage des données ou leur transfert vers une autre machine (plus lourd avec Subversion car si on change d'architecture - ou parfois même de version - on ne peut pas se contenter de copier la base, il faut l'exporter et la réimporter).

        - Arch supporte très bien les référentiels centralisés (un petit coup de tla-pqm par exemple), et permet plus de flexibilité dans les autres cas, qui deviennent plus courants (équipe offshore qui ne travaille pas exactement pareil, par exemple).

        Ceci dit, il est clair que Arch a besoin d'améliorer sa documentation et ses interfaces graphiques (il y en a en cours de développement). Mais Arch n'a pas les miyons de Subversion, donc ça prend plus de temps.

        • [^] # Re: Donc qu'est-ce qu'il vaut mieux utiliser ?

          Posté par  . Évalué à 1.

          Il est vrai que l'utilisation de DB par Subversion a quelques inconvénients. Maintenant que donne le système de Arch lorsqu'il commence à y avoir beaucoup de version de gros fichiers ?

          J'utilise professionnellement PVCS qui utilise des fichiers "normaux" pour stocker les révisions et lorsque les archives deviennent trop grosses (fichiers binaires modifiés souvent), les performances deviennent catastrophiques.

          • [^] # Re: Donc qu'est-ce qu'il vaut mieux utiliser ?

            Posté par  . Évalué à 1.

            PVCS Version Manager sans doute oui...

            Mais avec Dimensions qui est le produit supérieur dans la gamme tout est dans la base .

          • [^] # Re: Donc qu'est-ce qu'il vaut mieux utiliser ?

            Posté par  . Évalué à 1.

            des fichiers réguliers certes... mais binaires et propriétaires... bref lors de la corruption d'une archive, on est bon pour perdre tout l'historique du fichier asscocié... (j'utilise PVCS aussi... contraint et forcé)

    • [^] # Re: Donc qu'est-ce qu'il vaut mieux utiliser ?

      Posté par  . Évalué à 2.

      Je pense qu'il est illusoire de chercher le gestionnaire de version du futur, le bon gestionnaire dépendra avant tout des besoins du projet. Pour rester dans la comparaison CVS, Svn et Arch, je ne pense pas qu'il y a beaucoup de monde à avoir une expérience sérieuse sur les trois. Pour ma part j'aime beaucoup Subversion mais n'ayant aucune expérience sur Arch au dela de sa compilation, mon avis vaut probablement 0.

      De ton côté qu'est-ce qui ne t'avais pas convaincu dans Subversion ?

  • # Re: Sortie de Subversion 1.0.0

    Posté par  . Évalué à 1.

    Juste un petit post pour dire aux utilisateurs de (X)Emacs qu'un 'backend' VC existe en standard dans notre cher OS. Ca permet aux gens qui ne peuvent plus se passer des C-x v v de CVS de pouvoir tranquilement jouer avec subversion sans bousculer (trop) nos habitudes :)

  • # Ports de tla-1.1 (client Arch) sur OpenBSD

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

    Au passage, j'ai réalisé le port de tla-1.1 (client Arch "officiel" en C) sur OpenBSD 3.4 il y a quelques jours.

    J'en profite pour passer la news ici si certains d'entre vous veulent le tester et me renvoyer un statut de leurs tests. Cela me permettra de voir s'il n'y a pas de problème et de "pousser" les comitters OpenBSD à l'intégrer à l'arbre des ports officiels.

    URL pour récupérer une archive de mon port à tester : http://foxy.free.fr/OpenBSD/ports_tla-1.1.tar.gz(...)

    et message sur la ML 'openbsd-ports' pour plus de détails : http://marc.theaimsgroup.com/?l=openbsd-ports&m=107667378214976(...)

    Foxy (foxy free.fr)

  • # Marrant

    Posté par  . Évalué à -9.

    Trop marrant les commentaire sur Arch/Subversion.

    Les Alter-"tout et n'importe quoi" ont encore frappé...

    Subversion à le malheur d'être le successeur de CVS et donc le chois "naturel", "institutionnel".

    Du coup Subversion n'est pas assez rebèle et est même déjà "has been". Faut un truc qui arrache comme Arch même si notre rebèle en herbe n'a jamais fait un développement à plus de deux^W pardon un.

    Vous insultez les développeurs Subversion. Après faut pas vous étonner qu'il y ait des licences limites "à la con" comme XFree86.

    Un peu de respect pour Subversion (comme pour XFree86).
    Le logiciel libre est fait "avec amour" ; BORDEL !

    PS : J'y connais rien à Arch et c'est peut-être Le gestionnaire de version ultime. Mais un logiciel libre doit être respecté et pensez trentes secondes aux développeurs !

    • [^] # Re: Marrant

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

      Ben dans le genre Don Quichotte, t'es pas mal toi. Tu ramènes ta poire sur un sujet que tu ne connais pas à moitié (c'est toi qui le dis), tu balances des gros mots, tu montes sur tes grands chevaux et tu t'instigues en défenseur de quelque chose qui, pour autant qu'il me semble, n'a pas été attaqué !

      Toute la journée des gens qui préfèrent Subversion et d'autres qui préfèrent Arch ont dialogué et argumenté, se sont échangés opinions, informations et URLs, le tout sans que ça parte en trolls et autres enfilades infinies. Moi je trouve ça pas banal, et je tire mon chapeau à tous les participants aux discussions ci-dessus.

      J'ai l'impression que tu es rentré bien fatigué d'une longue journée harrassante, que voyant le sujet et certains mots clés (arch, subversion) tu t'es dis « ça va partir en troll », et tu as réagi comme si ça avait été le cas, sans prendre la peine de considérer ce qui s'était vraiment dit, sur le fond.

Suivre le flux des commentaires

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