Subversion rentre en phase alpha.

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
24
juil.
2002
Rien à voir
Subversion vient de rentrer en phase alpha avec un gel des fonctionnalités. Subversion (ou SVN pour les intimes) est LE remplaçant de CVS de la communauté open-source. C'est un gestionnaire de version puissant :
  • de vraies commandes cp, mv, rename côté client.
  • le versionnement des répertoires.
  • notions d'étiquetage et de branche.
  • le versionnement est fait pour une arborescence complète et non par fichier.
  • les changements sont atomiques (toutes les modifications de tous les fichiers sont prises en compte ou rien du tout).
  • accès réseau optimisé (un peu à la rsync).
  • possibilité d'attacher des propriétés à un fichier (type-mime, conversion de fin de ligne, icône etc...).
  • Subversion tourne sur tous les unix et sous windows !
A l'utilisation, sa prise en main est simple et son utilisation agréable. Il manque un client graphique (normal le backend est en cours de développement) mais il existe déjà une extension de nautilus (ou gnome-vfs) pour "browser" un dépôt. Pour les courageux, il est exploitable pour un projet (les développeurs de Subversion utilisent ... Subversion pour leur gestionnaire de version depuis 11 mois !). Néanmoins, mon expérience n'est pas très satisfaisante en l'utilisant avec Apache (peut-être un problème spécifique à ma machine). Vous pouvez visionner le dépôt actuel du subversion et utiliser l'actuelle et non finie interface web ici.
Pour l'installer, il faut apache 2.0.40 ... qui est en cours de développement. A bon entendeur ...
J'ai traduit leur handbook en français (il y a 2 semaines et 2/3 trucs ne sont plus à jour). Toutes les critiques sont appréciées.

Aller plus loin

  • # hép, modéros !

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

    Il y a un s/rendre/rentre/ à faire sur le titre, je crois.

    [-1]
    • [^] # Re: hép, modéros !

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

      rajoutons :

      s/atoniques/atomiques

      ... tant qu'on y est.

      Seb

      (-1 aussi, y a pas de raison ;o)
      • [^] # Re: hép, modéros !

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

        rah j'avais pas vu celle la, merci
      • [^] # Re: hép, modéros !

        Posté par  . Évalué à 8.

        et aussi:
        les developpeurs utilisent
        s/le depot actuelle du subversion/le depot actuel de subversion/

        bon ben il faut lire la traduction du handbook je pense ....
        • [^] # Re: hép, modéros !

          Posté par  . Évalué à 4.

          N'égourgeons pas tout de suite le modérateur.
          Pour "les developpeurs utilise" et "atonique", c'est moi!
      • [^] # Re: hép, modéros !

        Posté par  . Évalué à -2.

        ...Et puis aussi s/atomiques/transactionnels/ .

        parce que atomique, en francais, signifie pas du tout : "* (toutes les modifications de tous les fichiers sont prises en compte ou rien du tout)."

        C'est un changement <blinking>transactionnel</blinking>.

        atomique c'est destiné a des actions courtes, pas à une suite de 25 000 modifications a enregistrer ...

        mes 2 cents .
        • [^] # Re: hép, modéros !

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

          Pas forcément.
          Dans le monde des bases de données, l'atomicité est obtenue par les transactions. Mais on parle bien d'atomicité, c'est à dire d'indivisibilité (tout ou rien).
          La transaction n'est qu'un moyen d'obtenir l'atomicité.

          Ici, le terme atomicité est donc adéquat, je trouve.
          • [^] # Re: hép, modéros !

            Posté par  . Évalué à 10.

            Bon je voulais me l'ouvrir en chopant la définition qui tue dans le dico , mais je me suis planté ..


            * atomicité des transactions n. f. [.]
            [.]
            Déf. :
            Caractéristique obligatoire d'une transaction.

            Note(s) :
            Ce terme exprime qu'une transaction doit être considérée comme une opération indivisible, qui ne peut que s'exécuter entièrement ou, à défaut, être annulée entièrement.
            Dér. ATOMIQUE adj.
            PROTECTION DES DONNÉES.

            Donc l'atomicité est le 'tout ou rien'. Mais l'atomicité exprime une transaction. Les changements apporté à un CVN sont une transaction...


            Pour me ratrapper je joue sur les mots, et je signale que dans la langue francaises, seuls les
            transactions peuvent etre atomiques, et non pas les 'changements' ...
            </j'essaye d'attraper une branche>

            -1 , je vais me cacher derriere un arbre . Au fond de la foret. Loin.
    • [^] # Re: hép, modéros !

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

      Et un petit s/atoniques/atomiques/ sur le corps de la news, pendant qu'on y est.

      [-1 toujours]
    • [^] # Re: hép, modéros !

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

      J'ai du corriger quelques secondes avant ton commentaire (ainsi que d'autres fautes et un pb de format).
      Fabien, t'es pas bien reveillé ? :P
    • [^] # Re: hép, modéros !

      Posté par  . Évalué à -10.

      Vous allez jamais arrêter avec les remarques sur l'ortographe ?? on s'en fout
      Ca a l'air spécifique à linuxfr.org, sur d'autres sites genre slashdot je vois jamais ca
      Si tu n'as rien à dire tais-toi
      • [^] # Re: hép, modéros !

        Posté par  . Évalué à 3.

        Oui mais ça ne fait pas sérieux un site d'informations bourré de fautes, et une orthographe correcte améliore la lisibilité des articles.

        Pour slashdot, je ne pense pas qu'on puisse comparer, l'anglais étant réputé beaucoup moins ardu au niveau de l'orthographe que le français.
  • # Atonique

    Posté par  . Évalué à 10.

    Dans la news initiale (avant correction par les moderos), il y avait le terme 'atonique'. Le modero qui a corrige a remplace ca par atomique (c'est d'ailleurs ainsi que j'avais interprete le 'atonique') ; mais dans la traduction de la documentation on retrouve encore 'atonic'...
    Donc question: atonic, c'est une faute qu'on retrouve partout ou un mot manquant a mon vocabulaire ?
    • [^] # Re: Atonique

      Posté par  . Évalué à 10.

      C'est une erreur de ma part.
      C'est en passant pour un con qu'on progresse.
  • # Et cela vaut quoi ?

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

    Je suis en train de regarder un truc pour utiliser CVS dans des projets. Subversion apporte quoi qui fait vraiment ch... dans CVS ?

    Il compte rendre cela "stable" quand ?

    "La première sécurité est la liberté"

    • [^] # Re: Et cela vaut quoi ?

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

      Il y a plusieurs points déliquats dans cvs :
      Il y a le renommage ou le déplacement complet de sous arbres. Si, ça arrive, même sur des projets bien gérés.
      Il y a aussi une gestion « fichier par fichier » qui n'est pas forcément idéal pour tous les projets.
      Apparemment, Subversion propose des techniques pour ces deux points.
      • [^] # Re: Et cela vaut quoi ?

        Posté par  . Évalué à 10.

        La gestion des droits est aussi un peu casse pied dans cvs... c'est tout ou rien et ca c'est souvent genant en milieu industriel...
        subversion ca apporte des choses a ce niveau?
      • [^] # Re: Et cela vaut quoi ?

        Posté par  . Évalué à 10.

        Aussi un contrôle de l'intégrité du repository

        Un objectif essentiel d'un système de contrôle de versions est de garantir cette intégrité, je trouve hallucinnant qu'un fichier sur cvs puisse être corrompu (tout l'historique des modifications) sans qu'il y ait aucun checksum pour le détecter.

        Subversion a l'air très prometteur, j'espère remplacer cvs dès qu'il y a une version stable
    • [^] # Re: Et cela vaut quoi ?

      Posté par  . Évalué à 10.

      Ne serait-ce que pour le renommage des fichiers/répertoires, la gestion des fichiers binaires, la gestion d'arbo complètes (plutôt que de se reposer sur RCS qui suxe quand même pas mal)(et qui est plus conforme aux notions de release logicielles).

      Déjà pour ça, c'est bien (c)(tm)
      • [^] # Re: Et cela vaut quoi ?

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

        Et au niveau de la stabilité ? Pour des industriels ?

        nicO

        "La première sécurité est la liberté"

        • [^] # Re: Et cela vaut quoi ?

          Posté par  . Évalué à 10.

          > Et au niveau de la stabilité ? Pour des industriels ?

          Pour de la production, ce n'est pas près car trop récent (Alpha).
          La production c'est V1.0 + 3 à 6 mois.
        • [^] # Re: Et cela vaut quoi ?

          Posté par  . Évalué à 4.

          J'ai bien l'impression que les grosses boites vont utiliser encore plusieurs années ClearCase (l'usine à gaz de SCM de Rational).
          • [^] # Clearcase

            Posté par  . Évalué à 10.

            Lors de mon stage j'utilisais CVS, maintenant Clearcase.

            Je suis d'accord avec toi sur l'aspect "Usine à gaz", par contre ça me semble beaucoup plus puissant.

            Par exemple avec Clearcase, on peut créer des types de branches super complexe (config spec) dont les branches CVS ne sont qu'un sous-ensemble.

            Il y a aussi l'outil de merge qui est très performant. Il faut savoir que des personnes commes Marcello Tosatti, Alan Cox ou Linus passent 90 % de leurs temps à faire des merges.
            Dommage pour eux qu'ils n'aient pas de license Clearcase ! En même temps ça coute 2000 $ la license, et Bitkeeper c'est mieux que rien.
            • [^] # Re: Clearcase

              Posté par  . Évalué à 10.

              Hmm.. certes Clearcase est assez puissant, cependant d'après ce que j'en ai vu il est quand meme pas mal complexe a utiliser et il nécessite quasiment un admin car il est assez facile de bloquer le bazar (vues, replicats ...etc).
              Ca manque de transparence.

              En plus il necessite de n'utiliser QUE certaines distrib (RH en general, en tout cas jusqu'a la 4.2), a cause de leurs foutues modules dont on n'a evidemment pas les sources.

              Tout ca, sans compter le prix de la license, ca ne joue pas vraiment en sa faveur.
            • [^] # Re: Clearcase

              Posté par  . Évalué à 3.

              Quel outil de merge de Clearcase ?
              ca m'interesserai beaucoup d'en savoir plus (parce que xxdiff, c'est pas assez puissant pour moi)
              • [^] # outil de merge Clearcase

                Posté par  . Évalué à 1.

                Sous Windows, il y a MergeManager qui est graphique , ce qui est bien pratique : l'écran est subdivisé en deux, et tu peut comparer l'ancienne et la nouvelle version du fichier, les lignes qui changent étant colorée en bleu.

                Je précise que Clearcase n'est pas spécifique à Windows, l'interface de base est en ligne de commande, la partie graphique n'est qu'une surcouche, néanmoins bien utile.

                Le boulot du gestionnaire de merge consiste à arbitrer les conflits quand les deux développeurs ont touchés la même partie de code, de temps ils se trompe bien sûr, mais moins souvent que diff+patch par exemple (car il a plus d'info).
                • [^] # Re: outil de merge Clearcase

                  Posté par  . Évalué à 1.

                  En fait ce que tu appelles un gestionnaire de merge c'est juste un diff graphique (comme xxdiff) où les différence sont mises en couleurs et où tu cliques sur les modifications que tu veux conserver.

                  Un court instant, j'ai cru naivement qu'il existait un truc plus puissant qui aurait pu me rendre le boulot de merge plus facile...
                  • [^] # Re: outil de merge Clearcase

                    Posté par  . Évalué à 1.

                    Clearcase fait d'abord le merge ensuite il t'affiche le diff.

                    Maintenant si tu combine CVS pour les merges, un script PERL pour identifier les fichiers contenant des conflits plus un outils comme xxdiff, la tu effectivment que le Merge Manager de Clearcase.
              • [^] # Re: Clearcase

                Posté par  . Évalué à 1.

                tkdiff est bien fait, toujours selon le même principe des deux fenêtres + celle du merge.
                http://www.accurev.com/free/tkdiff/(...)
              • [^] # Re: Clearcase

                Posté par  . Évalué à 1.

                pour avoir passe un bout de temps sur la question du choix d'un outil de fusion de versions, l'offre est assez limitee compte-tenu de mes criteres:
                - *d'abord* fiable
                - pratique

                Faites gaffe en utilisant ces outils, ce n'est pas rare qu'ils 'mangent' des lignes en propageant une difference d'un fichier a l'autre !! mefiez-vous en comme de la peste !!

                Pour ma part j'ai choisi emacs ediff, tres puissant et *surtout* fiable
                • [^] # Re: Clearcase

                  Posté par  . Évalué à 0.

                  Faites gaffe en utilisant ces outils, ce n'est pas rare qu'ils 'mangent' des lignes
                  De la manière dont tu dis ça, on croirait que ta machine est hantée par un petit démon "mangeur de lignes"
                  ediff, tres puissant
                  En effet, il utilise un algo de merge à 3 fichiers : l'ancètre commun, la version du premier développeur, et la version du deuxième developpeur ... comme Clearcase d'ailleurs
                  *surtout* fiable
                  Le merge est par nature une opération non fiable car l'humain dispose de connaissance que la machine n'a pas (langage de programmation utilisé, langue française pour comprendre le sens des identificateurs ...).
                  D'ailleurs même les humains se trompent parfois !
    • [^] # Re: Et cela vaut quoi ?

      Posté par  . Évalué à 10.

      > Subversion apporte quoi qui fait vraiment ch... dans CVS ?

      voir ici : http://feliciano.matias.free.fr/svn/SVN-pour-les-utilisateurs-de-CV(...)

      > Il compte rendre cela "stable" quand ?

      Ben à partir de maintenant puisqu'il sont en alpha sans ajout de fonctionnalité (tient, t'as déjà la stabilité pour les fonctionnalité!).

      La version beta est prévue courant Septembre.
    • [^] # et arch?

      Posté par  . Évalué à 7.

      Quelqu'un a deja essaye arch qui, semble t il, fait plus ou moins la meme chose?
  • # Subversion est prêt pour le Desktop ?

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

    J'ai parcouru vite fait la doc, et il y a un point qui me gène.
    J'ai eu l'impression que la présence d'Apache était nécessaire pour utiliser Subversion.
    Est-ce parce-que j'ai mal compris, ou est-ce bien ça ?

    Sinon, il y a quelques points forts dans Subversion par rapport à cvs qui en font quelquechose d'intéressant, enfin le jour où ce sera stable (j'ai pas trop envi de confier mes travaux à un outil en version alpha).

    Par exemple, une véritable gestion d'arborescences complète.
    • [^] # Re: Subversion est prêt pour le Desktop ?

      Posté par  . Évalué à 10.

      Apache (avec mod_dav) est nécessaire uniquement pour un fonctionnement en mode serveur. Quand tout se passe en local, pas de problèmes.
      • [^] # Re: Subversion est prêt pour le Desktop ?

        Posté par  . Évalué à 10.

        Par contre apache (libapr) est nécessaire pour compiler subversion.
        Actuellement c'est un peut lourd d'installer apache-2.0, neon, db4 pour avoir subversion.

        Mais comme les futurs (très proches) distribes auront apache-2.0 en standard, çà va s'arranger.
        • [^] # Re: Subversion est prêt pour le Desktop ?

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

          C'est surtout très lourd d'avoir apache si on n'en a pas besoin.
          L'avantage de cvs, c'est qu'on peut mettre en place une petite machine dédié, sans trop de ressources (à part de stockage bien sûr).
          Quid de Subversion ?
          • [^] # Re: Subversion est prêt pour le Desktop ?

            Posté par  . Évalué à 10.

            Pour la compilation en mode local (i.e. pas client serveur), tu n'as besoin que de ça: http://svn.collab.net/repos/svn/branches/issue-749-dev/INSTALL(...) c'est à dire quelques librairies et logiciels. Les librairies apr & néon ne sont certes pas très courantes.

            Subversion a besoin d'Apache pour le serveur, parceque ça fonctionne avec mod_dav. Je pense que c'est une très bonne idée, c'est mieux que le pserver de CVS (mais peut-être moins bien que le fonctionnement sur SSH).

            Maintenant, je suis pas sur qu'en mode serveur Subversion soit énormément plus gourmant que CVS. ça permet tout de même de faire beaucoup plus de chose, et l'architecture n'est pas du tout la même. D'un côté, tu as besoin d'Apache, de l'autre, tu te débarasse (enfin) de RCS.
          • [^] # Re: Subversion est prêt pour le Desktop ?

            Posté par  . Évalué à 6.

            > C'est surtout très lourd d'avoir apache si on n'en a pas besoin.

            Le problème, c'est libapr qui est une couche qui facilite la portabilité. Subversion tourne sur Unix Mac OS X , Windowns, etc... Et çà en version Alpha. Leur choix d'utiliser libapr est bon.

            Le problème est que libapr est livré avec Apache 2.0 et n'est pas encore totalement séparé d'apache : C'est en cours.

            Je me suis fait des packages rpm d'apache-2.0 qui s'épare libapr d'apache. Sur une becane qui doit rester en Apache 1.3 j'ai :
            apache-1.3.22-2
            httpd-libapr-utils-0.2002.06.25-1
            httpd-libapr-0.2002.06.25-1
            subversion-0.13.2-2639

            => Donc du peut utiliser Subversion sans Apache 2.0.

            sur un autre becane, utilisée pour compilier subversion :
            httpd-2.0.40-1
            httpd-devel-2.0.40-1
            httpd-libapr-0.2002.06.25-1
            httpd-libapr-devel-0.2002.06.25-1
            httpd-libapr-utils-0.2002.06.25-1
            httpd-libapr-utils-devel-0.2002.06.25-1
            subversion-devel-0.13.2-2639
            subversion-0.13.2-2639
            subversion-server-0.13.2-2639

            Ici, pour avoir Subversion-server il me faut apache.
            • [^] # Re: Subversion est prêt pour le Desktop ?

              Posté par  . Évalué à 1.

              Je vois pas ce qu'il y a de si compliqué à installer Apache 1.x et 2.x dans des dossiers séparés ...
              • [^] # Re: Subversion est prêt pour le Desktop ?

                Posté par  . Évalué à 2.

                Il n'y en a pas. C'est même la procédure proposée par la doc de subversion.

                C'était, entre autre, pour indiquer qu'il est possible d'installer (et sûrement de compiller) subversion sur une bécane avec apache 1.3 ou sans apache (bien sûr, il n'y aura pas subversion-serveur).

                Si çà intéresse quelqu'un, je peut mettre les packages libapr* en ligne (y doivent d'ailleur être sur le site de subversion!).

                Néanmoins, il n'est pas très "pûre" d'installer apache 2 alors que tu n'en a pas besoin...
        • [^] # Re: Subversion est prêt pour le Desktop ?

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

          Mais comme les futurs (très proches) distribes auront apache-2.0 en standard, çà va s'arranger.

          Vu que faire cohabiter PHP4 & Apache 2.0 ca reste encore de la bidouille, va falloir attendre au moins la sortie de PHP 4.3 et Apache 2.0.40 pour ca... Et après même si Mandraket et Redhat en seront équipés, pour les distribs serieuses faudra attendre encore un peu <TROLL>surtout chez Debian, faudra attendre 3 ans maintenant pour la nouvelle version</TROLL>.
    • [^] # Re: Subversion est prêt pour le Desktop ?

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

      Un dernier point.
      Je n'ai pas vu dans la doc s'il est possible ou non de rappatrier un projet de cvs vers Subversion.
      Puisque Subversion se prétend successeur de cvs, ce serait une très bonne chose, voire même indispensable.
      Ce n'est pas non plus, semble-t-il dans les « features planned »
  • # Oui, mais cependant

    Posté par  . Évalué à -10.

    Nautilus sux

    Donc subversion aura un quelconque intérêt quand on pourra l'utiliser de manière graphique dans un vrai environnement, dépouvu de gnomeries.

    (mhhh, à combien ça va descendre ça? ;) )
    • [^] # Re: Oui, mais cependant

      Posté par  . Évalué à -1.

      > quand on pourra l'utiliser de manière graphique dans un vrai environnement, dépouvu de gnomeries.

      Tu veux dire un truc qui n'utilise que libX11, comme xbill ?

      Erreur, xbill c'est de la merde il utilise aussi libXt.

      Le top du top reste l'utilisation de ncurses avec aalib pour les graphiques.

      Sinon, tu peux me dire ce que te retourne un équivalent de :
      $ rpm -q --whatrequires libgnome.so.32
      • [^] # Re: Oui, mais cependant

        Posté par  . Évalué à 1.

        Bah y'a pas que GNOME dans sous X, y'a aussi des toolkits réellement utilisables. Pour faire de vraies applications, je veux dire.

        Sinon quand je fais rpm -q --whatrequires libgnome.so.32, j'ai tout une liste d'applications qui suxent et qui s'appellent gnomemachin, gnomebidule, abiword, trucmuch-gnome. Ca prouve quoi, que les apps gnome ont besoin de gnome?

        (et hop, à la truelle! :p Je me repentirai un autre jour :) )
  • # Doc en francais et HTML

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

    La doc en français utilise des liens avec accents et mon pauvre IE n'a pas l'air d'aimer du tout (erreur 404).

    nicO

    "La première sécurité est la liberté"

  • # <i>c'est normal ?</i>

    Posté par  . Évalué à -10.

    c'est normal qu'ils utilisent CVS pour leur suivi de version ?

    -1, c'est que le début...
    • [^] # Re: <i>c'est normal ?</i>

      Posté par  . Évalué à 3.

      -2 parceque tu as dû mal lire.

      http://subversion.tigris.org/(...)

      Il y a un énorme pavé jaune. Lis.
      • [^] # Re: <i>c'est normal ?</i>

        Posté par  . Évalué à -4.

        On peut meme plus troller tranquilement, il faut se mettre au courant maintenant ?

        -1 ne suffit pas, je vais mettre des gros smileys la prochaine fois...

        -1 aussi
        • [^] # Re: <i>c'est normal ?</i>

          Posté par  . Évalué à 2.

          Un bon troll est un troll argumenté de données justes aux interprétations moins justes. Moi, pour ce que j'en dit, il devrait y avoir possibilité d'avoir un niveau -troll- dans les posts qu'on ne pourrait pas noter.
          • [^] # Re: <i>c'est normal ?</i>

            Posté par  . Évalué à 5.

            mmm tu as pas tout à fait tort. Mais moi je veux pouvoir poster en ayant à peine lu la news, pas du tout les liens et pas scrollé les commentaires, et ça les gens peuvent pas comprendre.
            comment ça pollution ? ;-)
            je mérite des baffes et je le sais.

            N'empèche que j'ai déjà essayé les posts ressemblant à ce que tu décris, ça donne http://linuxfr.org/topic/Suse/8497,0,-1,2,1.php3(...) et c'est pire. j'ai du perdre 45 XP sur cette news, à l'aise. (note que modérer une news à troll à 1h du mat ça mobilise que les moules).

            PS : il m'est arrivé de mettre des posts sérieux. Ils sont plus durs à trouver, il est vrai.
  • # Les paris sont ouverts

    Posté par  . Évalué à 7.

    La question la plus intéressante dans l'histoire, selon moi, c'est:
    Est-ce que Linus va utiliser subversion et abandonner bitkeeper?

    Personnellement, je parie 10¤ qu'il va envoyer tout le monde chier en disant que c'est de la merde et garder son bk!

    Et vous? Vous en pensez quoi?
    • [^] # Re: Les paris sont ouverts

      Posté par  . Évalué à 10.

      Que le singe préfère la voiture rouge. Et que tant qu'il ne m'oblige pas à en acheter une rouge aussi, ça ne me dérange pas.
    • [^] # Re: Les paris sont ouverts

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

      Dans une dépêche précédente sur subversion, Linus a déjà été cité et il disait que Subversion n'offrait pas toutes les fonctionnalités de Bitkeeper. J'ai pas retrouvé le lien sur Google :(
      • [^] # Re: Les paris sont ouverts

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

        « I took a look at subversion, and it doesn't even come close to what I wanted. (...) And I personally refuse to use inferior tools because of ideology. »

        http://www.uwsg.iu.edu/hypermail/linux/kernel/0203.0/1646.html(...)
        • [^] # Re: Les paris sont ouverts

          Posté par  . Évalué à 1.

          Ouais, c'est un peu ce que je pensais qu'il aurait comme réaction. Je risque pas de perdre d'euros sur ce coup là :)

          And I personally refuse to use inferior tools because of ideology.

          Juste en passant, je trouve ça quand même grave venant d'un mec qui met son code sous GPL. Il ne s'est pas encore rendu compte que la GPL n'était qu'idéologie?
          Pour utiliser une image comme l'a fait Aurélien_qui_n_a_pas_l_air_d_être_trés_content,
          c'est comme si un flic venait à l'école pour faire une intervention contre la drogue aux gamins et, qu'une fois terminé, il se balladait en fumant un gros tarpé dans la cour...
          • [^] # Linus et la GPL

            Posté par  . Évalué à 8.

            Bah le noyau Linux s'est retrouvé sous GPL par pur hasard parce que Linus était frusté de ne pas avoir pu s'amuser avec Minix (dont la license interdisait tout modification) ce qui l'a forcé à tout reprendre de zéro (d'où Linux).

            Si Minix n'avait pas existé le noyau Linux serait probablement pas GPL (peut-être BSD ?).
          • [^] # Re: Les paris sont ouverts

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

            > c'est comme si un flic venait à l'école pour faire une intervention contre la drogue aux gamins
            > et, qu'une fois terminé, il se balladait en fumant un gros tarpé dans la cour...

            Ton image est mauvaise car Linus ne code pas par ideologie mais par plaisir. Il ne plaide pas pour la GPL et la liberation du logiciel, il se contente de coder. Il y en a beaucoup ici qui devraient suivre son exemple.
            • [^] # Re: Les paris sont ouverts

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

              Il y en a beaucoup ici qui devraient suivre son exemple.

              houhou ! mais c'est qu'il est taquin ;^)
            • [^] # Re: Les paris sont ouverts

              Posté par  . Évalué à 0.

              Ce n'est pas le code qui permet de faire avancer les choses mais bien l'idéologie.
              Si la GPL n'existait pas et qu'il n'y avait que la licence BSD, tu penses que les entreprises auraient pris la peine de contribuer gentillement au code? Jamais de la vie! Ils auraient tout pillé sans vergogne.
              Il a été prouvé que ms utilisait du code bsd. Tu les vois faire des améliorations et les fournir au développeur?
              Je pense au contraire qu'il n'y a rien de plus dangereux pour le mouvement du libre que les gens qui codent en GPL sans totalement adhérer à l'idéologie de la GPL.
              Si tu codes pour le plaisir et que tu ne veux pas te prendre la tête avec toute cette histoire d'idéologie, la BSD est là pour ça ou autre. Pas la GPL.
              C'est normal que Linus se fasse tirer les oreilles parce qu'il utilise les avantages de la GPL (toutes les contributions extérieures qui lui permettent de faire avancer le noyau et de garder le contrôle dessus; la protection du travail qu'il effectue face à tous les rapaces ambiants,...) mais refuse de contribuer à son expansion en faisant passer l'idéologie inhérente à la GPL comme un désavantage. Un développeur, quel que soit son nombre de ligne/journée et la qualité de son code est avant tout un homme.
              En tant que personne, je préfère largement celui qui code et qui fait ça dans un but de partage que celui qui code comme un dingue pour son seul plaisir.
              • [^] # Re: Les paris sont ouverts

                Posté par  . Évalué à 4.

                Linus ne communique pas non plus sur les desavantages de la GPL. faut pas pousser ...

                Linus dit simplement qu'il s'en moque. Quand il a eu besoin d'une license suffisemment libre pour que son travail puisse profiter a TOUT le monde, on lui a conseille la GPL, il a suivi le conseil. Point. Le reste ne l'interesse pas.

                peut-on lui en vouloir pour cela ??
  • # Une question...

    Posté par  . Évalué à 5.

    Est-il possible de définir des dépendances entre projets avec Subversion ?
    Par ex, j'ai 2 projets, un programme et une lib,
    le programme utilise la lib en statique et je veux garder comme info quelle version de lib a été utilisée pour compiler une certaine version du programme.

    Je n'ai encore jamais vu d'outil de gestion de source capable de faire ça, mais je n'ai peut-être pas les yeux en face des trous...
    • [^] # Re: Une question...

      Posté par  . Évalué à 2.

      Il me semble que tu essaies de te compliquer la vie.
      L'etape de la compilation et de la resolution dependances n'a pas (amha) a etre gere par l'outil de gestion de version. On lui demande avant toute chose de garder une trace de l'evolution d'un groupe de fichiers, pas de gerer des trucs qu'il ne comprend pas comme la compilation.

      Pour faire ce que tu veux, il vaut mieux utiliser des systemes comme dpkg qui te permettent d'avoir des dependances au moment de la compilation et de l'installation. Dpkg est fait pour cela et il le fait tres bien.
      Quant a garder une copie des options de compils, le plus simple est d'inclure dans ta librairie un numero de version ainsi qu'une fonction du type :

      #define MY_LIB_VERSION 2002072401
      int getversion(void)
      {
      return(MY_LIB_VERSION);
      }

      et de modifier le #define lors de vrais changements (comme la modification de l'API publique de la librairie)
    • [^] # Re: Une question...

      Posté par  . Évalué à 3.

      en general on ne stocke pas le binaire mais les sources, donc aucun resultat de compilation.
      pour ton probleme (quelle version a ete utilisee pour compiler), un petit coup de "what" ou "ident" sur ton binaire devrait te donner la reponse si le developpeur a inclus les tags qui vont bien (en tout cas cela marche comme ca avec CVS).

      sinon est-ce que ton soft ne pourrait pas etre un sous-projet de ta lib ??
    • [^] # Re: Une question...

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

      Cela m'interresse beaucoup ce genre de chose. J'ai un projet qui peut en inclure un autre et qui sera probablement inclue lui-même dans un autre.(c'est en électronique)

      Comment faire pour s'en sortir proprement et avec les dépendances ? Et si, de plus, il y a des dépendances sur des versions particulières ?

      "La première sécurité est la liberté"

    • [^] # Re: Une question...

      Posté par  . Évalué à 1.

      ClearCase peut te faire ca. C'est de Rational Software, c'est baleze, tourne sur un paquet de plateformes, et bien sur c'est pas Free.
      • [^] # Et en libre ?

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

        Il n'y a rien de libre pour ça ?

        nicO

        "La première sécurité est la liberté"

        • [^] # Re: Et en libre ?

          Posté par  . Évalué à 1.

          Rien a ma connaissance...

          J'ai developpé pour ma boite un ensemble de scripts perl qui attaquent un soft de gestion de source proprietaire (sic). À la base le soft propose l'équivalent de CVS, mais avec la surcouche ça gere maintenant les dépendances.

          J'ai envie de refaire ce genre d'outil en GPL, mais j'hésite entre baser ces scripts sur CVS ou prendre Subversion...
  • # Versionnement + question aux admins

    Posté par  (Mastodon) . Évalué à 4.

    Ouais, ouais, ouais : je ne sais pas si ça n'est pas un peu pénible, d'avoir une gestion des versions par arborescence complète au lieu des fichiers. J'avoue ne pas avoir pris le temps de consulter les détails de SubVersion, mais moi je trouve que c'est bien d'avoir une gestion par fichier, parce que c'est précis et on peu laisser des traces détaillées de l'histoire de chaque fichier, clairement identifiées. Pour les traitements d'ensemble, on utilise des tags.
    L'idéal étant peut être quand même de pouvoir faire les deux en fonction des besoins.

    Note pour les admins :
    Ca m'enerveeeeuuu, mais je n'arrive pas à poster certains commentaires : Mozilla finit par emettre un "Document contains no data" et rien ne bouge. Cela ne semble arriver qu'au delà d'un certain niveau de profondeur des threads.
    • [^] # Re: Versionnement + question aux admins

      Posté par  . Évalué à 3.

      moi aussi STOP.
      gros problem pour poster depuis plusieurs semaines STOP.
      peut-etre du a longueur du post STOP.
    • [^] # Re: Versionnement + question aux admins

      Posté par  . Évalué à 3.

      > mais moi je trouve que c'est bien d'avoir une gestion par fichier
      > on peu laisser des traces détaillées de l'histoire de chaque fichier :

      çà reste valable :

      $ svn log subversion.spec-mat.patch
      ------------------------------------------------------------------------
      rev 46: f.matias | 2002-07-23 02:28:34 -0400 (mar, 23 jui 2002) | 1 line

      Revert de subversion.spec subversion.spec-mat.patch.
      ------------------------------------------------------------------------
      rev 31: anonymous | 2002-07-17 02:27:36 -0400 (mer, 17 jui 2002) | 1 line

      Petit adaptation de packages/rpm/subversion.spec-mat.patch pour suivre les modifs de subversion.spec.
      ------------------------------------------------------------------------
      rev 25: anonymous | 2002-07-16 19:34:52 -0400 (mar, 16 jui 2002) | 1 line

      Tous ce qui est spécifique à matias contient "-mat".
      ------------------------------------------------------------------------
      rev 24: anonymous | 2002-07-16 19:14:53 -0400 (mar, 16 jui 2002) | 1 line

      Mise à jour des patchs pour construire les packages rpm.

      - - - - - - - - - - - - - - - - -


      Sinon, si tu tients à travailler à l'ancienne, une ne fait des modifications de l'aborescence qu'un fichier à la fois :

      $ svn commit -m "Ajout blague du jour" README
      Version 10 commited
      $ svn commit -m "Ajout blague du jour" cmdline.c
      Version 11 commited
      $ svn commit -m "Ajout blague du jour" cmdline.h
      Version 12 commited


      Perso, je trouve çà ridicule.
      • [^] # Re: Versionnement + question aux admins

        Posté par  (Mastodon) . Évalué à 1.

        ça reste valable :
        Ok, tant mieux. Sur le coup, l'idée qu'une modif de fichier changait le versionnage de tout le projet m'a un peu choqué. Ca va mieux maintenant, merci. Le poids des habitudes, sans doute ...
        Vivement les versions beta puis finale et des front-ends sympas ...
        • [^] # Re: Versionnement + question aux admins

          Posté par  . Évalué à 2.

          > Sur le coup, l'idée qu'une modif de fichier changait le versionnage de tout le projet m'a un peu choqué.

          désolé, on c'est mal compris, mais de peu. Un exemple pour éclairir "ta lanterne" :
          $ svn status -v
          _ 59 57 f.matias .
          _ 59 2 anonymou ./Makefile
          _ 59 27 anonymou ./Makefile-mat.patch
          _ 59 2 anonymou ./README
          _ 59 2 anonymou ./install.patch
          _ 59 24 anonymou ./install.patch-mat.patch
          _ 59 46 f.matias ./subversion.spec
          M 59 57 f.matias ./subversion.spec-mat.patch


          Le 59 c'est le numéro de révision de l'arborescence complète à laquel correspond l'ensemble de mes fichier. Tous commit (ci) même d'un unique fichier change ce numéros. Les chiffres à droite du 59 est le numéro de l'arborescence lorsque le fichier a été modifié.

          Mais Makefile:2, Makefile-mat.patch:27, etc... correspond à l'arborescence 59.

          Ainsi, Makefile, README, install-patch qui ont le numéro 2 on été "check in" en même temps.

          Si on les "check in" un par un alors:
          Makefile => 2
          README => 3
          install-patch => 4

          et ce sont les seules fichiers qui ont leur numéros de révision de dernière modification à 2, 3, 4.

          Les numéros de version sont TOUJOURS pour toute l'arborescence. Mais on peut connaitre les numéros de version où un fichier a été modifier :

          exemple :
          $ svn log install.patch-mat.patch
          ------------------------------------------------------------------------
          rev 24: anonymous | 2002-07-16 19:14:53 -0400 (mar, 16 jui 2002) | 1 line

          Mise à jour des patchs pour construire les packages rpm.
          ------------------------------------------------------------------------
          rev 22: anonymous | 2002-07-16 17:35:28 -0400 (mar, 16 jui 2002) | 1 line

          patchs spécifiques pour créer les packages rpm. Ne marche peut-etre pas actuellement.
          ------------------------------------------------------------------------

          Le fichier a été modifié deux fois : à la révision 22 et 24 de l'aborescente.

          Si je veux la première version :

          svn co ... -r 22 install.patch-mat.patch


          Ce n'est pas génant.

          lit cette courte page :
          http://feliciano.matias.free.fr/svn/Transactions-et-num%E9ro-de-r%E(...)

          > changait le versionnage de tout le projet m'a un peu choqué.

          Il y a aussi l'étiquetage, voir http://svn.collab.net/repos/svn/tags/(...) pour un exemple.

          Franchement Subversion est exploitable et plus simple et naturel que cvs. Si tu ambitionnes (pour un nouveau projet) utiliser un gestionnaire de version, çà peut-être un bon choix.
          • [^] # Re: Versionnement + question aux admins

            Posté par  (Mastodon) . Évalué à 1.

            Merci pour tes explications très complètes.
            Par contre :
            Si tu ambitionnes (pour un nouveau projet) utiliser un gestionnaire de version, çà peut-être un bon choix.
            Ca coince : ma boîte a choisi PVCS (de Merant), et on a beau avoir argumenté que l'on utilisait CVS depuis belle lurette dans l'équipe, il n'y a pas grand chose à faire, malheureusement ...

Suivre le flux des commentaires

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