Subversion 1.4.4

Posté par  . Modéré par Florent Zara.
Étiquettes :
0
24
juin
2007
Communauté
Ce 08 juin, Subversion, le célèbre gestionnaire de version, est sorti en version 1.4.4.

Subversion est un système de gestion de version, qui a été développé dès 2000 par CollabNet dans le but de remplacer CVS comme logiciel standard de contrôle de révision dans le monde du libre. La version 1.0 est sortie au terme de 5 ans de conception et de développement et regroupe maintenant une communauté très active. La majorité des projets libres qui utilisaient CVS sont passés à SVN au fil du temps.

SVN est sous licence BSD. L'équipe ne propose pas de binaires de Subversion par défaut aussi faut-il parfois un peu de temps pour voir arriver la dernière version sur son OS. Subversion est disponible sous GNU/Linux, NetBSD, FreeBSD, OpenBSD, Solaris, MacOSx, IBM i5/OS et l'autre. Deuxième version de l'année pour la branche 1.4.x, cette version est une simple version de correction qui propose une mise à jour de chaque élément de la distribution (client, serveur, etc.). La liste complète des modifications est visible dans le fichier CHANGES.

En plus des correctifs, on notera :
  • une mise à jour des langues Chinois simplifié, Japonais et Norvégien ;
  • "make svnserveautocheck" permet de tester les cibles ;
  • la correction d'erreurs dans les bindings javahl, SWIG/perl, SWIG/python et SWIG/ruby.

Aller plus loin

  • # "l'autre"

    Posté par  . Évalué à 8.

    C'est si difficile que ça de dire Microsoft Windows ? -_-
    • [^] # Re: "l'autre"

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

      Ça fait 10 caractères de plus, c'est pas décroissance.
      /o/ ===>[]
    • [^] # Re: "l'autre"

      Posté par  . Évalué à 9.

      à force de parler de "l'autre" sur linuxfr, faudrait pas que ça devienne le premier site trouvé lors d'une recherche sur l'autre moteur de recherche...
    • [^] # Re: "l'autre"

      Posté par  . Évalué à 0.

      Moi, je trouve qu'il n'a pas été assez loin, à la place de "l'autre", j'aurais mis "l'autre bouse"
  • # Mercurial/SVN

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

    Vivement la version qui intègrera le branch merge/tracking, parce que svn fait un peu pitié par rapport à murcurial sur ce plan, ce qui lui manque pour être le scm parfait.
  • # Clearcase

    Posté par  . Évalué à 2.

    Pour les malheureux obligés de bosser avec clearcase, un connecteur subversion existe maintenant, cf http://blogs.open.collab.net/svn/2007/06/subversion-conn.htm(...)
    • [^] # Re: Clearcase

      Posté par  . Évalué à 2.

      Pourquoi malheureux ?

      Qu'est-ce que subversion a de mieux ?

      Personellement, je bosse avec clearcase, et je ne trouve pas subversion particulièrement sexy.
      • [^] # Re: Clearcase

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

        Clearcase est proprio, captif (tu ne peux pas en migrer) et un vrai plat de spaghetti dans les SI...
        • [^] # Re: Clearcase

          Posté par  . Évalué à 2.

          A part le libre c'est mieux ?

          L'utilisation de vue avec montage nfs de l'arbo, sans rapatrier l'ensemble du projet, ...

          Ma vision, probablement fausse de svn, c'est qu'on récupère un projet complet, ensuite, on commit tous les fichiers qui ont bougé.

          Peut-on reserver un fichier qu'on checkout ? Enfin, ce genre de chose.

          J'aimerais avoir un vrai comparatif, pas des pseudo argument chez moi, j'utiliserai svn mais chez un client ? Quels sont les avantages de svn s'il y en a ?
          • [^] # Re: Clearcase

            Posté par  . Évalué à 5.

            Bon allez je vais te lister quelques unes des différences


            vue dynamique:

            SVN ne fournit que l'équivalent des vues snapshots et pas de vues dynamiques.
            Avantage:
            pas besoin de charger les données

            Inconvénient:
            Mode connecté => dépend du bon état du réseau, pas de possibilité de travailler hors ligne, simple point of failure si le serveur de registre ou de vob tombe

            Vue snapshot,dynamique vs workspace SVN.:

            Ne fonctionne que dans une architecture réseau commune (droits à allouer sur le postes, création d'un compte service dans le domaine.
            Performance dégradées à distance au point que le multisite ou les clients Web deviennent incontournables.

            Avec SVN derrière un frontend Apache pas de pb de performance
            Solution IBM pour la 7.0 => CCRC qui revient à fournir le modèle SVN .

            Obligation d'administrer les vues car lors des co le serveur de registres garde la trace des fichiers réservés.
            Il faut purger régulièrement de registres les vues qui ne sont plus utilisées.
            Avec SVN pas de trace. Si un fichier est locké par un utilisateur on peut forcer le unlock et on a pas de trace

            Gestion des licences:
            coût des licences et simple point of failure lorsque le serveur est out.


            Modèle de concurrence:
            obligation de réserver un fichier (même en unreserved ) avant de le modifier pour CC.
            SVN : possibilité de choisir pour certain fichiers un fonctionnement avec un lock exclusif (fichier images par exemple) et modifiication sans réserver les fichiers pours les autres.


            Gestion des droits administrateurs
            Avec CC lié à l'OS => nécessite de contacter les admins pour créer un compte chaque fois qu'on veut ajouter un nouvel utilsateur (pour compliquer le tout obligation d'avoir le même compte sur tous les OS créer le compte dasn Active Dirctory et le recréer sur le serveurs Linux)


            Multisite:
            Mise en ouevre complexe et nécessaire à cause des perfs lorsque 2 réseaux d'entreprise sont différent et distants.
            Avec SVN l'approche centarlisée convient et l'administation derrière Apache permet de ne pas être liée à l'archietcture du réseau (un login et un pw suffisent). IBM propose le CCRC pour contourne le pb dans la 7.0



            Merge et intégration
            Avantage à CC qui propose depuis tjs le merge tracking (hyperlien de merge), des assistants de merge pour une arborescence complètes et des interfaces de merges adaptés à des fichiers autres que seulement du texte (XML, modèles Rose, RSM, , word, ...)



            Triggers
            Placés du coté des clients avec CC suaf depuis la 7.0 avec le CCRC.
            permet d'intrecepter plus d'opération mais necessite de les déployer sur chacun des clients et de les porter sur tous le OS.


            Fabrication:
            Cleamake permet le partage d'objets dérivés et l'audit de fabrication
            Pb aujourd'hui ANT ou compil incrémentale pour Java

            Gestion des changement
            Clearcase de bas n'a pas de commit atomique (changeset)
            => obligation d'utiliser UCM pour s'interconnecter avec un outils de change/bug tracking.

            Pas de gestion des composants à la UCM pour SVN

            ....
            • [^] # Re: Clearcase

              Posté par  . Évalué à 2.

              Ah oui j'oubliais.

              Obligation de faire des montages NFS pour bosser entre les stations de travail sous Linux et les serveurs même avec des vues snapshots alors que CCFS uitilse juste du RPC sous Windows. Intéressant sur des sites distants.

              Pour accéder à l' API on a le choix entre COM/DCOM (Windows only) , ccperl (don't feed the troll) ou le parsing du CLI. à comparer avec l'API de SVN et ses 2 couches et la facilité de créer des wrappers (python, SVNkit, .....)

              Allez je vais arrêter là.
        • [^] # Re: Clearcase

          Posté par  . Évalué à 1.

          Sans parler du prix délirant et de MVFS qui te force à utiliser une distrib particulière .. en fait la liste des défauts de ce truc n'a pas vraiment de fin.

          Mais sinon c'est rigolo de voir que ceux qui l'utilisent sont près à mourir plutôt que passer à autre chose. J'ai du louper un truc à l'époque !
          • [^] # Re: Clearcase

            Posté par  . Évalué à 3.

            Desole, mais non, je ne connais pas svn suffisamment pour savoir que c'est mieux. Alors à part des posts sterils :
            -- 'Pourquoi c'est mieux ?'
            -- 'Ouarff le nul, il sait même pas que c'est mieux'
            -- 'Explique moi ?'
            -- 'Hihihi, il sais pas que c'est libre'
            -- 'Oui, enfin, t'a un vrai argument ?'
            -- 'Ouarff il est nul, il sait pas que c'est mieux...'

            Bon, je ne suis pas sur, mais il me semblait avoir quitté la maternelle depuis un moment, alors soit quelqu'un sait faire une comparaison ou bien je ne serais pas plus avancé. Mais les remarque qui servent à rien, ne font, amha, pas avancer le shimlblik.
            • [^] # Re: Clearcase

              Posté par  . Évalué à 4.

              Je m'auto-réponds : j'ai trouvé deux sites qui en parle:
              http://pipoware.free.fr/wordpress/?p=154
              http://better-scm.berlios.de/comparison/comparison.html

              il y en a certainement d'autre.
            • [^] # Re: Clearcase

              Posté par  . Évalué à 2.

              Je n'ai pas dit que c'était mieux (relis et pas entre les lignes), pour cela il faudrait faire une comparaison approfondie des fonctionnalités dans les différents modes et notamment avec l'utilisation de SVK.

              Non, par contre, j'ai constaté à l'utilisation, que je ne trouvais AUCUN argument en faveur d'une utilisation de Clearcase tout simplement. Et on ne peux même pas se retrancher derrière le parapluie "on a IBM derrière", il m'est arrivé de m'entendre répondre que le bug qui nous empêchait de produire serait corrigé .. dans 6 mois ! C'est pourquoi, alors qu'aujourd'hui je ne l'utilise plus, je plains ceux qui sont obligés de se le farcir.
        • [^] # Re: Clearcase

          Posté par  . Évalué à 2.

          Je ne vois pas en quoi l'utilisation de Clearcase rend captif l'utilsateur.

          A partir du moment où tu as toutes les versions de fichiers d'un projet tu peux tjs les récupérer par script une par une et alimenter un dépôt d'un autre gestionnaire de version
          • [^] # Re: Clearcase

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

            Sans perdre l'historique ? Parce que mine de rien, c'est plutôt ça la VA d'un gestionnaire de versions concurrentes.
            • [^] # Re: Clearcase

              Posté par  . Évalué à 2.

              Oui avec l'historique.

              Avec un cleartool find bien paramétré tu peux récupèrer l'historique de tous les éléments, répertoires y compris.
              Tu peux aussi te baser sur le clearexport_ccase
              ou encore partir de la racine la racine de ta vob, récupérer son arbre de version, et descendre récursivement dans chacune des versions de répertoires.

              En revanche avant de remonter ces versions tu dois appliquer un traitement pour reconstituer des baselines ou des révisions de façon cohérente .

              Sans ce traitement tu risques de te retrouver avec un repository incompréhensible car CC pratique le versionning au niveau des elts et SVN au niveau de l'arborescence entière. Un fichier ou répertoire regroupe tout son historique dans l'arbre de version de l'elt auquel il est associé alors qu'avec SVN modifier une version de fichier revient à créer une nouvelle configuration i.e une nouvelle révision de toute ton arborescence.

              Il faut donc bien réfléchir à la stratégie d'import.
              Par exemple regrouper toutes les versions d'arborescence qui ont tiré la branche v1.0 sous CC dans le répertoire /branches/v1.0/mon_projet/
              et les baselines labelllisées sous /label/ (exemple /label/V1.0-r1/mon_projet/)

              Sinon si tu remontes chronologiquement, tu va te retrouver avec des révisions qui ne seront pas logiquement liées entre elles (genre la révision 43 qui correspond à la release 2.3 sera suivie par la révision 44 qui correspond au dernier patch de la 1.5 avec des. On récupère 2 arboresence mon_projet mais pas moyen de voir à quoi elle corresponde.

              Si tu remontes sans traitement préalable c'est encore pire, tu auras un historique du genre
              rev 1:
              /src

              rev 2:
              /src
              /src/package1

              rev 3:
              /src
              /src/package1
              /src
              /src/package2

              rev 4:
              /src
              /src/package1/f1.java (version /main/1 de f1.java)
              /src
              /src/package2


              rev 5:
              /src
              /src/package1/f1.java (version /main/v0.1/1 de f1.java)
              /src
              /src/package2

              /src
              /src/package1/f1.java (version /main/v0.1/1 de f1.java)
              /src
              /src/package2/f2.java (version /main/1 de f2.java qui n'a jamais été associé à f1.java/main/v0.1/1 dans aucune vue)
              Bref tu auras l'historique des fichiers mais aucune baseline

Suivre le flux des commentaires

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