Subversion 1.2

Posté par  . Modéré par Jaimé Ragnagna.
Étiquettes : aucune
0
26
mai
2005
Communauté
Suversion est un logiciel de contrôle de version centralisé. Son but est de devenir le remplaçant de l'antique CVS. Il en corrige bon nombre de défauts (gestion simple des branches, versionnement des répertoires, déplacement des fichiers simples, gestion des liens et fichiers spéciaux, métadonnées associées aux fichiers, transactions atomiques et bien d'autre choses).

La version 1.2 vient d'être rendue publique. Avec cette nouvelle version, Subversion apparaît comme une alternative sérieuse à d'autres logiciels dans des environnements précis. Subversion supporte maintenant la gestion du verrouillage ( reserved check-out) : une personne peut se réserver les droits d'écriture sur un fichier et les autres ne pourront y accéder qu'en lecture tant que le verrou existe.

L'implémentation Webdav de subversion propose l'auto-versioning : lorsque vous enregistrez une nouvelle version de votre fichier sur un partage Webdav, une nouvelle version de ce fichier est créée.

Pour finir, en plus du lot de corrections de bugs, une mise à jour de sécurité : sous Microsoft Windows, le client en ligne de commande chiffre le mot de passe utilisé pour l'accès au serveur.

Aller plus loin

  • # Darcs 1.0.3

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

    Marrant, Darcs 1.0.3 est vient de sortir aussi. C'est une version assez mineure, donc ce n'est pas la peine d'en faire une dépêche, alors autant profiter de celle-ci pour rappeler son existance. Darcs 1.0.4 apportera par contre un grand lot d'optimisations (vitesse, conso mémoire), et là on pourra en parler dans une vraie dépêche pour lui tout seul.

    Plus d'infos sur Darcs : http://www.darcs.net/(...)

  • # Verrouillage

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

    Subversion supporte maintenant la gestion du verrouillage ( reserved check-out) : une personne peut se réserver les droits d'écriture sur un fichier et les autres ne pourront y accéder qu'en lecture tant que le verrou existe.

    Heu pardon ? On pense bien à la même chose, à la fonctionnalité que tous les gestionnaires de sources « à l'ancienne » possèdent, qui a fait grincer les dents de milliers de développeurs dans le monde alors qu'ils courraient à la poursuite de l'inévitable couillon qui avait oublié de retirer son verrou, et que CVS est venu plus ou moins enterrer dans un grand concert de « ouf » de soulagement ? (Même si CVS supporte cette fonctionnalité en fait, je crois.)

    Franchement, on est au XXIè siècle, je sais bien que les années 70 sont à la mode, mais là c'est abuser !

    • [^] # Re: Verrouillage

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

      C'est pourtant indispensable si tu veux faire une énorme mise a jour qui peut breaker plein de choses, et que tu ne veux pas passer 40 ans derrière a régler les conflits de merge a la mano parcequ'un crétin aura jugé bon de traffiquer le code pendant que tu travaillais, meme en supposant que les devs s'étaient coordonnés avant... (les boulets ça existe chez les devs aussi).
      Ce genre de features, meme si elles sont a utiliser avec modération peuvent s'avérer indispensables dans certains cas pour éviter des merdes futures...

      • [^] # Re: Verrouillage

        Posté par  . Évalué à 7.

        s/breaker/casser/
        s/merge/fusion/
        s/features/fonctionnalités/

        à part ça je suis bien d'accord ;-)

    • [^] # Re: Verrouillage

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

      Les développeurs de subversion avaient pourtant expliqué (très clairement) dans le manuel que le lock ne résous pas grand chose, mais ils l'ont fait à la demande des utilisateurs.

      Et oui, les mentalités mettent du temps à changer. Je pourrais citer un ingénieur qualité disant, en l'an 2005, « surtout, pensez bien à *toujours* locker les fichiers sur lesquels vous travaillez avant de les modifier. Sinon, qui fera le merge ? ».

      • [^] # Re: Verrouillage

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

        Qu'y a-t-il de si choquant a vérouiller un fichier en écriture pour s'assurer de l'écriture correcte du fichier ? Sans intervention exterieur ?

        • [^] # Re: Verrouillage

          Posté par  . Évalué à 2.

          ce qui est choquant c'est surtout le "toujours"

        • [^] # Re: Verrouillage

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

          Ça n'a rien a voir avec la vérification de l'écriture correcte. Ce n'est pas un verrouillage de ta copie de travail, c'est un verrou sur le serveur, c'est a dire que pendant que tu travailles sur un fichier (entre le checkout et le commit), toutes les autres personnes qui travaillent sur le même projet sont priés de ne pas modifier ce fichier.

          Le but même d'un gestionnaire de version, c'est de travailler sur plusieurs versions concurrentes d'un même fichier. Si tu interdit toujours cette concurrence des versions, ce dont tu as besoin, c'est plutôt d'un système de backup.

          http://svnbook.red-bean.com/en/1.1/ch02s02.html#svn-ch-2-sect-2.2(...)

        • [^] # Re: Verrouillage

          Posté par  . Évalué à 3.

          Ca n'a pas l'air choquant, mais tous ceux qui ont eu l'occasion de travailler avec ce genre de méthode se rappellent les moments maudits où un clampin a oublié un verrou avant de partir en week-end (ou de tomber malade) et où il faut de toute urgence récupérer un accès privilégié sur le serveur pour annuler le verrou.

    • [^] # Re: Verrouillage

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

      Le seul intérêt qu'on peut voir est lorsque tu travailles avec un objet de type binaire. Exemple : un modèle de base de données.
      Cela serait dommage que tu perdes tes modifications parce qu'un de tes camarades à dégainer plus vite que toi pour commiter....


      --
      C01N C01N

      • [^] # Re: Verrouillage

        Posté par  . Évalué à 2.

        Tes modifs ne seront pas perdues, elles seront dans la dernière version. Celle de ton collègue dans l'avant dernière. Et ensuite, vous devrez vous taper le merge à la main.

        • [^] # Re: Verrouillage

          Posté par  . Évalué à 2.

          pourquoi il faut faire le merge à la main ? le serveur ne peut pasfusionner automatiquement si ça ne touche pas aux mêmes parties du fichier ?

          • [^] # Re: Verrouillage

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

            Pour un fichier binaire quelconque, jouer à la roulette russe me parait moins risqué.

            Maintenant, il y a pleins de cas particuliers où un outil spécialisé pourrait faire quelque chose (typiquement, un document OOo).

            • [^] # Re: Verrouillage

              Posté par  . Évalué à 0.

              au boulot, on utilise MS SourceSafe, qui a pas mal de petits problèmes mais qui réalise avec brio la fusion automatique. C'est extrêmement rare d'avoir des problèmes avec ça ici.

              • [^] # Re: Verrouillage

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

                Sur quel type de fichiers tu fais ça ?

                On parle bien de fichiers binaires ici. Pour les fichiers textes, effectivement, la fusion se fait très bien. C'est le principe de base d'un gestionnaire de versions, en fait.

                • [^] # Re: Verrouillage

                  Posté par  . Évalué à 1.

                  euh... oui, je parlais de fishier texte, désolé /o\

          • [^] # Re: Verrouillage

            Posté par  . Évalué à 3.

            pourquoi il faut faire le merge à la main ? le serveur ne peut pasfusionner automatiquement si ça ne touche pas aux mêmes parties du fichier ?

            Mouais et si y a par exemple des checksums apres le merge tu sera super content...

            D'ou l'interet d'utiliser un maximun des fichiers texte comme xml (bon apres xml n'est pas genial non plus, vu que les logiciels ont tendance a pas aller a la ligne...)

        • [^] # Re: Verrouillage

          Posté par  . Évalué à 4.

          En fait, c'est un peu plus compliqué que ca.

          L'intêret de la reservation du fichier concerne certains types de fichiers, qui ne disposent pas de gestionnaire de fusion adapté.

          La plupart des logiciels de contôle de version gèrent parfaitement la fusion de document de type texte (sources).

          Il existe un certain nombre de fichier qui ont besoin d'outils adaptés.
          Par un exemple, travailler en concurrence sur un modèle UML stocké sous forme de fichier XMI (dtd XML) implique de fusionner les modifications à la main entre les différentes balises XML, ce qui n'est pas trivial.
          Donc soit le logiciel de contrôle de version est extensible et permet de lancer un interface (graphique et souvent proprio) de fusion adapté, soit il vaut peut être mieux n'autoriser qu'un accès séquentiel au fichier.
          Comme exemple d'outil proposant ces interface de fusion, il y a Rose , Word .....

          Il y a aussi les fichiers que l'on versionne mais qu'on ne peut carrément pas fusionner.
          Viendrait il a quelqu'un l'idée de fusionner le .png qui représente le logo de son site, édité en concurrence sous Gimp?

    • [^] # Re: Verrouillage

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

      Ben si des gens le veulent on l'implémente. C'est ce qu'a fait subversion. Si tu crois, comme eux, que c'est inutile, rien ne t'empêche de ne pas l'utiliser.

      Attention tout de même, il s'agit d'un mode coopératif. D'après les releases notes tout le monde peut dévérouiller le fichier à l'aide d'un "--force"/ Pas besoin donc de courrir après le couillon. L'admin peut lui aussi dévérouiller quoi qu'il se passe.

    • [^] # Re: Verrouillage

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

      alors qu'ils courraient à la poursuite de l'inévitable couillon qui avait oublié de retirer son verrou

      Subversion 1.2 t'indique le user qui a locké le fichier.

      Mais le lock c'est aussi un truc intéressant pour apprendre qu'une autre personne est en train de travailler sur le même fichier que toi.

      • [^] # Re: Verrouillage

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

        Subversion 1.2 t'indique le user qui a locké le fichier.

        Bien sûr, comme tous les outils qui font du verouillage. Le problème concret, c'est qu'il ne t'indique pas où le couillon se trouve. En réunion ? À la cafèt' ? Chez lui ? Coups de fils, déplacements, pertes de temps, généralement dans un contexte où tu as besoin de modifier le fichier. Heureusement que Subersion permet de forcer les choses, lui.

        Mais le lock c'est aussi un truc intéressant pour apprendre qu'une autre personne est en train de travailler sur le même fichier que toi.

        Ouais super, on sait pas ce qu'il fait, on sait pas où il en est, on sait juste que ce que nous on ne va pas pouvoir faire, c'est bosser (dessus). Ça remplace pas une bonne communication (mailing-list, réunions).

        Le verrou peut avoir des utilisations ponctuelles bien utiles voire indispensables (voir autres réponses), mais de manière générale, c'est une horreur.

        • [^] # Re: Verrouillage

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

          Une bonne utilisation de ce genre de choses, c'est un couplage fort entre ton bug/feature tracker et ton gestionnaire de versions. Il parait que clearcase fait à peu près ça :

          Pour changer un truc dans le code, il faut passer par le tracker. Dans le tracker, une fois que le changement a effectuer est assigné à un développeur, il signale qu'il va avoir besoin de modifier les fichiers X, Y et Z, ça apparait dans le tracker et ça lock effectivement les fichiers dans le gestionnaire de versions. Ensuite, le commit qui corrige le bug le ferme dans le tracker et libère les fichiers (ceci dit, ce modèle ne s'applique que très difficilement au développement open-source communautaire).

          • [^] # Re: Verrouillage

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

            Ouaip ca s'appelle UCM (Unified Change Management) qui s'interface entre Rationnal ClearCase et Rationnal DDTS (si je ne m'abuse).

            C'est tres bien adapté à la phase de maintenance d'une version d'un soft (correction de bug, tout ca).

            Mais ca marche moins bien en mode dévelopement. Même si en théorie tu dois toujours coder qqch qui se raccroche à une activité qui est elle même trackée, etc. En pratique, lorsque tu développe un nouveau truc ce model est plus contraignant qu'autre chose.

            • [^] # Re: Verrouillage

              Posté par  . Évalué à 3.

              UCM (Unified Change Management) est en fait une surcouche de Clearcase qui définit des entités de plus haut niveau (activité, stream, ...) et qui permet de s'interfacer avec des outils de change request (idéalement venant d'IBM on a Rational Clearquest :-(

              Une activité est associée à une version modifiée de plusieurs fichiers et peut donc être assimilée à un changeset.
              Le fait d'extraire les fichiers en écriture avant toute modification permet de tracer les activités et d'affiner la gestion des demandes de changements.

              UCM a été créé pour pallier un gros manque de Clearcase de base: Les transactions sur le commit se font au niveau du fichier et non pas au niveau du changeset.
              Ca signifie que si vous décidez de lancer un commit sur l'ensemble de vos fichiers modifiés, tous ceux qui n'ont pas été modifiés par un tiers sont commités et les autres sont rejetés. Vous devez résoudre les conflits restant alors que vous avez remis un changement incomplet; au risque qu'un autre récupère la moitié des modifs dans son espace de travail avec un update (=> pb compil, core dump, ...).

              Rational a résolu le problème en associant une branche à chaque développeur, une branche d'intégration commune et en créant 2 actions au niveau du changeset ("rebase" equivalent à "update" et "deliver" équivalent à "commit").

              Bref Rational a réinventé CVS en plus compliqué en rajoutant un peu de crème de RUP, de gestion composant... pour plaire aux décideurs et vendre des licences hors de prix.
              On obtient un outil complexe avec une architecture scabreuse et qui demande beaucoup d'administration.

              Si on veut un outil proprio qui gère la notion de changement, qui marche aussi bien voire mieux pour moins cher (gratuit pour les projets open source) autant se rabattre sur Perforce.
              http://www.perforce.com/perforce/technical.html(...)
              http://www.perforce.com/perforce/fr/price.html(...)

              Si on veut vraiment dépenser des sous pour un "méga tool de la mort qui tue" alors autant choisir spectrum SCM qui est un outil complet avec une architecture solide et propre.
              http://www.spectrumscm.com/(...)

              Mais franchement, une combinaison SVN/trac ou SVN/scarab (sur tigris.org comme SVN) donnera autant satisfaction que UCM/Clearquest pour bien moins cher.
              http://scarab.tigris.org/(...)

        • [^] # Re: Verrouillage

          Posté par  . Évalué à 3.

          En fait il faut faire la différence entre l'extraction en vue d'une édition (checkout) et la reservation d'un jeton d'exclusivité.

          Pour certains outils (Clearcase, Perforce -jesaisapsaipalibre), les fichiers que l'on récupère dans son repertoire de travail sont tous en lecture seule. Pour editer un fichier, il est nécessaire de l'extraire en ecriture explicitement ('cleartool co' ou 'p4 edit'). On a donc un accès au serveur qui permet de tracer les accès au fichiers.
          L'intêret est donc plus pour le chef de projet qui peut gérer plus finement la répartition des changements et leur livraisons.Les outils de bug tracking disposent alors de plus d'informations et la gestion de projet est plus précise. (cf. Perforce)
          L'autre avantage est qu'on peut réassocier une modifcation déjà effectuée sur un fichier à un autre changement plutôt qu'en faire une copie et effacer les modifications (svn revert)

          Lors de l'extraction, il est aussi possible d'obtenir un jeton d'exclusivité sur le fichier que l'on veut editer, ce qui permet d'eviter qu'un autre n'edite le même fichier que toi.(interessant pour certains types de fichiers uniquement).

          Par défaut avec des outils comme CVS et SVN, le bloquage se fait au moment de la remise (commit).
          On n'est pas prévenu qu'un objet est déjà édité, car on a déjà les droits d'écriture dessus. Il faut donc prendre l'initiative de consulter le serveur pour vérifier que personne ne l'a edité. De même, il est necessaire que chacun s'astreigne à réserver le fichier avant modification, et il est facile d'oublier.(SVN permet de forcer la politique précédente)

          Un autre intêret du lock concerne le commit.
          , lorsqu'on travaille sur un changement qui concerne de nombreux fichiers:
          Au moment de comitter, il se trouve qu'un ficher que l'on a modifié, a déjà été remis. On merge donc les différences, on reteste et paf!!! un autre fichier a été remis entre temps. On risque de merger ad vitam eternam sans jamais pouvoir remettre son changement.
          Le solution: verrouiller tous les fichiers que l'on a édité afin d'empêcher les autres de comitter, le temps que l'on ait résolu les conflits de merges.

          L'outil idéal est donc celui qui permet de définir sa politique de concurrence d'accès.
          1/ Fichier en ecriture et résoulution des conflits au meoment du commit
          2/ Fichiers en lecture seule, action d'éditer le fichier afin de tracer les changements et résolution des conflits au moment du commit
          3/ Fichiers en lecture seule et possibilité de le réserver en exclusivité
          4/ Possibilté de réserver le fichier pour être prioritire sur la remise
          5/ Bien entendu, il doit être possible de forcer les verrous

          Je ne sais pas comment se comporte SVN 1.2 mais j'ai cru comprendre qu'il était possible de mettre en place toutes les politiques sauf la 2 au moyen des hooks
          http://svn.collab.net/repos/svn/trunk/notes/locking/locking-functio(...)
          Il faudra que teste pour en être sûr.

          En conclusion: ces politiques centralisées correspondent mieux à des besoins entreprises qu'à des developpements OpenSource.
          Avec des outils distribués il me parait beaucoup plus délicat de mettre en place une administration centralisée de ce type (lock inter-repository).SVN me semble plus complet sur ces attentes.

          • [^] # Re: Verrouillage

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

            > 1/ Fichier en ecriture et résoulution des conflits au meoment du commit

            Surtout pas au moment du commit. Le commit, il dit "Ma version locale (que j'ai testée) devient la version de référence". Le merge doit se faire au moment de l'update (qui doit toujours précéder un commit dans le modèle centralisé).

            • [^] # Re: Verrouillage

              Posté par  . Évalué à 2.

              Ce que je voulais dire c'est que c'est au moment du commit qu'on s'apercoit qu'il y a a des conflit car on est rejeté.
              On peut faire un update avant pour vérifier, mais même après , il y un un intervalle de temps avant le commit pendant lequel quelqu'un d'autre peut commiter. Donc dans tous les outils avec un schéma de concurrence optimiste (à la CVS) l'opération de commit peut échouer pour cause de conflit.

  • # Tant qu'on est dans les annonces ...

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

    bazaar, client GNU arch, sort dans quelques jours en version 1.4. Pas de changement radical cette fois par rapport à la version 1.3, mais beaucoup de petites améliorations, et beaucoup de nettoyage de code en interne (comprendre: Rien a court terme pour l'utilisateur, mais c'est bon signe pour la suite).

    http://bazaar.canonical.com/(...)

    Et dans le monde de GNU Arch, Xtla est sorti en version 1.0 hier. Xtla, c'est l'interface Arch pour Emacs, j'en parlais ici http://linuxfr.org/~moy/15924.html(...) et depuis, il n'y a eu à peu près que des bugfixes dans la branche 1.0. Par contre, quelques nouveautés intéressantes, en particulier le support de bazaar, dans la version de développement, future 1.1

    http://wiki.gnuarch.org/xtla(...)

  • # suivi des merge?

    Posté par  . Évalué à 1.

    A quand une trace des merge et des copy dans le log?

    • [^] # Re: suivi des merge?

      Posté par  . Évalué à 2.

      Peut-être pourriez-vous voter (moi c'est déjà fait) pour l'issue 820 ( http://subversion.tigris.org/issues/show_bug.cgi?id=820(...) ) car ce n'est pas dans les préocupation du moment si j'en crois la roadmap ( http://subversion.tigris.org/roadmap.html(...) ).

      • [^] # Re: suivi des merge?

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

        > ce n'est pas dans les préocupation du moment si j'en crois la roadmap
        > ( http://subversion.tigris.org/roadmap.html(...) ).

        Sur cette page, je lis pourtant

        Medium-term Goals:
        [...]
        * merge tracking (describes a whole class of problems)

        Je pense que c'est a ça qu'ils font allusion.

        • [^] # Re: suivi des merge?

          Posté par  . Évalué à 2.

          Le but du vote serait de faire passer cette fonctionnalité en préocupation du moment. Par "Medium-term Goals" je comprend qu'ils y pensent mais pas pour tout de suite. Pourtant en parlant avec plusieurs utilisateurs de subversion c'est souvent ce problème qui ressort en premier.

          Pour pallier à ce manque nous utilisons des scripts pour faire le merge. Ces scripts renseignent au fur et à mesure un fichier texte avec les révisions qui ont été mergé. Au moment du commit on recopie manuellement le contenu de ce fichier dans le message de log. Ca serait bien d'automatiser tout ça dans subversion.

          • [^] # Re: suivi des merge?

            Posté par  . Évalué à 2.

            Pourtant en parlant avec plusieurs utilisateurs de subversion c'est souvent ce problème qui ressort en premier.

            Comme le dit un commentaire sous le rapport de bug, l'enjeu est plus général :
            « What's mentioned above is *so* just the tip of the iceberg.
            Resummarize to reflect the true scope of this issue. »

            Pouvoir taper un simple "svn merge" au lieu d'aller chercher à la main les numéros de révision à inclure (au risque d'en oublier une parce qu'on ne se souvient jamais si les bornes de l'intervalle sont inclues dedans ou pas...), ce serait une avancée énorme. Le "SVN book" dit que c'est prévu dans l'avenir de Subversion, mais n'entre pas dans les détails.

    • [^] # Re: suivi des merge?

      Posté par  . Évalué à 1.

      En attendant, on peux s'en sortir comme ca:
      http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-4-sect-3.3.(...)


      Tracking Merges Manually
      ...
      What does this mean to you, the user? It means that until the day Subversion grows this feature, you'll have to track merge information yourself. The best place to do this is in the commit log-message. As demonstrated in the earlier example, it's recommended that your log-message mention a specific revision number (or range of revisions) that are being merged into your branch. Later on, you can run svn log to review which changes your branch already contains. This will allow you to carefully construct a subsequent svn merge command that won't be redundant with previously ported changes.

      In the next section, we'll show some examples of this technique in action.

      • [^] # Re: suivi des merge?

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

        Mouais, enfin, c'est quand même vrai qu'après avoir utiliser un gestionnaire de version avec suivi des merges, on se demande comment on faisait avant ! Avec bazaar, par exemple : 
        $ baz missing <la branche du copain> -s
patch-42
    corrigé pleins de bugs
patch-34
    ajouté une killer-feature
...
$ baz merge <la branche du copain>
=> ça récupère tous les changements depuis le dernier merge.

  • # Comparatif ?

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

    Etant de l'ancienne ecole, j'ai plutot l'habitude de CVS. Hors si quelqu'un a une experience avec plusieurs de ces nouvelles alternatives (j'avais jamais entendu parler de darcs par exemple ...) avec avantages/inconvenients, ce serait bien de faire une petite presentation en reponse.

    J'avoue que le but est de mettre en place un systeme pour gerer des projets entre 5/6 personnes et l'idee de (re)mettre un CVS me revulse.

    Steph

Suivre le flux des commentaires

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