Subversion 1.7

Posté par  . Modéré par baud123. Licence CC By‑SA.
Étiquettes :
40
12
oct.
2011
Gestion de versions

Apache Subversion 1.7 est sorti le 11 octobre. Attendue de longue date, cette version majeure apporte de nombreux changements dans lesquels on ressent l’influence de la popularité croissante des gestionnaires de versions décentralisés.

Cette version 1.7 est compatible avec les versions précédentes, côtés client et serveur, même si les nouvelles fonctionnalités (détaillées dans la seconde partie de la dépêche) ne seront pas toutes disponibles.

Liste des nouveautés

  • un répertoire « .svn/ » unique à la racine de la copie de travail. Fini le répertoire « .svn/ » dans tous les répertoires du projet. Pour mettre à jour une copie locale existante, il faut utiliser « svn upgrade » ;
  • amélioration de l’utilisation du protocole HTTP ;
  • nouvel outil d’administration svnrdump offrant les mêmes fonctionnalités que svnadmin, mais qui peut être utilisé depuis un client (svnadmin nécessite les droits administrateur sur le serveur) ;
  • « svn diff » utilise maintenant le format unifié par défaut. Une nouvelle option « --git » permet d’ajouter des informations pour les fichiers ajoutés, supprimés ou copiés, et produit des patches compatibles avec git-apply ;
  • nouvelle commande « svn patch » pour appliquer des patches au format diff unifié ;
  • « svn log » peut afficher les différences avec l’option « --diff » ;
  • « svn relocate » permet de changer l’URL d’un dépôt et remplace la commande « svn switch --relocate » ;
  • amélioration des fusions (merges).

Popularité : svn versus les dvcs

Aller plus loin

  • # Euh, mercurial est écrit en perl ?

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

    C'est une blague cette comparaison sur Ohloh, il a détecté que mercurial était écrit en perl !!! J'ai du rater un épisode, tout le monde sait qu'il est en parrot !

    Sinon, la comparaison n'est pas très intéressante, elle mesure juste le dynamisme des projets eux-même. Ce qui serait plus intéressant, c'est de mesurer le nombre de projet utilisant respectivement mercurial, subversion ou git. C'est ce qui est fait ici:
    http://www.ohloh.net/repositories/compare

    Et on voit que mercurial se prend une grosse grosse claque. Dommage, moi j'aime bien ce projet. On voit aussi que subversion domine encore le monde, ce qui me semble logique. On change pas de VCS comme ça, encore moins pour passer d'un truc compréhensible par les non geeks comme un VCS centralisé à un truc incompréhensible même par certains geeks, comme git.

    Cela dit, à côté de mercurial, bazaar peut aller se rhabiller...

    Quand je vois la place de CVS aussi, ça fait pleurer un peu. Worse is better, n'oublions pas !

  • # Indétrônable en entreprise

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

    En entreprise, Subversion semble encore bien tenir la route. Les manageurs connaissent, le concept de dépôt centralisé les caresse dans le sens du poil, les utilisateurs sont canalisés dans un processus de développement (développement sur le tronc, et branches de releases ou de fonctionnalités), et tout le monde sait à peu près l'utiliser (ça se gâte quand on commence à toucher aux branches). Les utilisateurs chevronnés passent par git-svn, et tout le monde est content.

    Aucune des améliorations de la 1.7 n'est particulièrement enthousiasmante, mais c'est bien de voir que le boulot continue. Bon courage aux mainteneurs!

    • [^] # Re: Indétrônable en entreprise

      Posté par  . Évalué à 2.

      Certes, mais git gagne du terrain : beaucoup de SSII s'y mettent, constatant la plus grande souplesse (moi-même, j'étais assez dubitatif, et je m'y mets).
      De plus git peut fonctionner "au-dessus" de SVN (cad, svn coté serveur, git coté client).

      Les managers vont de plus en plus devoir s'y faire : git colle plus à la philosophie agile que SVN. Et ces choses s'affirment car elles sont particulièrement adaptées aux projet de taille petite et moyenne, ce qui correspond à la majorité des cas.
      Je ne dis pas que git est supérieur ou non à svn, mais il faut avouer que pour une utilisation standard, il est relativement simple en comparaison...

      • [^] # Re: Indétrônable en entreprise

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

        ... Et moi qui suis bloqué avec bien pire, j'ai nommé la grosse usine à gaz malodorante qu'est ClearCase. J'ai essayé de parler de Git, mais l'ankylose a bien trop pris là où je bosse.

        • [^] # Re: Indétrônable en entreprise

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

          Goute donc à Serena Dimension. Un petit exemple pour la route : ce qui s'apparente à un commit + tag sous SVN d'un projet de taille moyenne prends une demie journée avec cette chose.

          SVN reste parfaitement adapté pour des projet de moyennes importance, chacun pouvant l'utiliser sans trop remettre en question ses habitudes.

      • [^] # Re: Indétrônable en entreprise

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

        Pour un public non informaticien, passer de rien à SVN est déjà pas mal... je le vend enrobé de TRAC histoire d'avoir un peu de doc avec !

        Ne pas oublier qu'un avantage de SVN est de forcer la centralisation. Dans le cadre de mon laboratoire de recherche, cela permet de savoir un peu qui fait quoi et donc espérer plus de collaboration et d'échange entre les personnes. Je sais bien que c'est aussi un inconvénient... Enfin, sur les projets sur le TRAC, on a une histoire relativement bonne des projets et du code.

        Pb: comme on versionne cette daube de LabView ? Avez-vous des solutions satisfaisantes pour ce genre de programme ?

        • [^] # Re: Indétrônable en entreprise

          Posté par  . Évalué à 3.

          Pb: comme on versionne cette daube de LabView ? Avez-vous des solutions satisfaisantes pour ce genre de programme ?

          J'ai posé la question pendant 4 ans dans ma précédente boite.
          Il paraît qu'il y a un truc intégré dedans pour le versioning. En pratique "c'est pas la peine, je sais ce que j'ai changé! -ah oui quand même..."

        • [^] # Re: Indétrônable en entreprise

          Posté par  . Évalué à 3.

          je le vend enrobé de TRAC histoire d'avoir un peu de doc avec !

          j'utilisais trac aussi avant mais quand tu as goûté à redmine, tu n'hésites plus tu prends redmine.

          • [^] # Re: Indétrônable en entreprise

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

            J'ai une centaine de projet sous trac avec des utilisateurs qui ont appris à l'utiliser. Je changerais bien à terme mais se pose le problème de la migration. Il est hors de question de migrer sans les wikis actuels !

      • [^] # Re: Indétrônable en entreprise

        Posté par  . Évalué à 3.

        Et aux projets de grosse taille aussi, comme, au hasard, le kernel Linux...

    • [^] # Re: Indétrônable en entreprise

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

      Je suis d'accord Subversion a encore de beaux jours devant lui en entreprise.

      J'ai tenté de migrer en mercurial il y a un an et après 1/2 journée d'explications aux chefs de projets avec explication des intérêts et l'officialisation d'un rôle d'intégrateur et je me suis fait rembarré.

      Au final Subversion marche bien mais un dvcs permet souvent de clarifier les rôles et les responsabilités de chacun.

      Sinon concernant cette version 1.7 : pas de grandes nouveautés et du retard par rapport à la date prévue (fin septembre).

      J'ai l'impression que l'activité de développement baisse, ça ne me rassure pas.

      • [^] # Re: Indétrônable en entreprise

        Posté par  . Évalué à 10.

        Dans une migration vers un autre gestionnaire de source, l'aspect humain est je pense beaucoup plus important que l'aspect technique. Je pense que pour réussir sa migration, il faut plusieurs ingrédients :

        1. commencer par mettre en place une solution qui change le moins de chose possible, c'est à dire garder le même workflow (un repository centralisé qui sert à tout le monde)
        2. mettre à disposition des docs très simples à suivre pas à pas pour les actions de base, c'est à dire :
          • faire un checkout
          • faire un commit
          • faire un merge
        3. utiliser le DVCS pendant quelques temps sans changer les habitudes

        Avec ce système, on voit déjà l'intérêt de Git ou Hg par une gestion des merges beaucoup plus puissante qui donne beaucoup moins de conflit, on peut aussi commencer à voir qu'on peut faire des commits dans son coin sans impacter personne et ainsi jalonner son travail.

        Le changement du workflow peut se faire dans un second temps. Je suis d'accord avec toit qu'un workflow intégrateur est très intéressant mais il est plus facile de le vendre comme un changement d'habitude que comme un changement d'habitude et d'outil.

        Si on regarde le projet PostgreSQL, ils ont fait une transition de CVS vers git, mais pour le moment, ils n'utilisent qu'une partie de git, par exemple ils se refusent à faire des merges et font uniquement des rebase pour garder un historique linéaire comme ils en avaient l'habitude avant. Ils ont maintenant les bases techniques pour faire des changement d'organisation plus tard. (voir à ce sujet l'article sur l'indispensable lwn : Lessons from PostgreSQL's Git transition

        Pour terminer, il est intéressant de bien vendre sa migration. C'est à dire repérer dans l'outil actuel ce qui pose problème : dans une migration que j'ai eu à faire, on utilisait svn avec des branches et l'équipe était relativement nombreuse (une petit quinzaine). Les merges devenaient vraiment compliqué, malgré l'utilisation de svnmerge (plus tard intégré à la version 1.6 de svn si mes souvenirs sont bons). J'ai commencé à faire des essais avec git-svn, puis sur un développement que j'avais à faire avec quelqu'un d'autre nous avons travaillé à 2 avec git. L'opération étant concluante, il a fallu bien préparer la migration et convertissant tous les outils (divers scripts, intégration continue, génération des fiches de version logiciel, etc.) et préparer des docs hyper directives. La migration a pu être vendue sur la facilité des merges par rapport à l'outil précédent et le fait que tout soit prêt à l'avance a permit de limiter les problèmes techniques rencontrés et grandement facilité l'adoption.

        Étienne

        • [^] # Re: Indétrônable en entreprise

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

          Merci de ton retour expérience.

          Je suis globalement d'accord avec toi : pour ce genre de migration il faut être très pédagogue et prendre le temps.

          Pour finir sur mon expérience nous sommes toujours sur Subversion mais le rôle d'intégrateur est parfaitement intégré (j'ai fait l'inverse de ton cas) et on se demande comment on faisait avant. Quelques développeurs (en plus de moi) utilisent hgsubversion avec TortoiseHg et je pense que le passage à un dvcs commence à murir.

          J'attends juste de voir comment va évoluer git sur un environnement Windows pour ne pas partir sur Mercurial et migrer vers Git un an après.

          Merci encore.

      • [^] # Re: Indétrônable en entreprise

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

        du retard par rapport à la date prévue (fin septembre).

        15 jours seulement... Je te trouve un peu dur ;-)

  • # rapidité accrue

    Posté par  . Évalué à 5.

    J'ai compilé svn 1.7 hier car je travaille sur de nombreux projets sous SVN et j'en suis très satisfait, les améliorations en termes de rapidité sur des dépôts très volumineux (dizaines de milliers de fichiers et dossiers) sont énormes grâce à la modernisation du format de dépôt local (facteur 10 pour moi, je passe d'une à deux minutes pour un svn up à quelques secondes). Ce qui est vraiment bien c'est que je bénéficie du gros des améliorations alors que le serveur sur lequel je travaille est toujours en 1.6 et ne migrera probablement pas avant longtemps. TortoiseSVN a aussi été mis à jour pour mes contributeurs sous Windows et ils sont apparemment aussi très contents des gains de perf.

    Si votre serveur est en 1.6, n'hésitez donc pas à passer votre client en 1.7, inutile d'attendre une migration en 1.7 des dépôts :)

  • # Transition

    Posté par  . Évalué à 1.

    Comment peut-on passer la transition ?

    Peut-on avoir des clients en version 1.7 et un serveur en version 1.6 ? Peut-on déjà y voir un gain ?
    Et l'inverse ?

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Nouveautés ?

    Posté par  . Évalué à 1.

    J'ai l'impression que les nouveautés ne sont tip-top non plus.

    Il y a des nouveautés mises en avant qui font vraiment pas rêver:
    svn relocate: cela laisse rêveur ...
    svnrdump: pas mal mais non désactivable apparemment.

    Personnellement, là où j'ai les plus galéré avec SVN c'est dans les merges ... Il y avait des tree conflicts à la con dont avait peine à déterminer l'origine.

    • [^] # Re: Nouveautés ?

      Posté par  . Évalué à 3.

      svnrdump: pas mal mais non désactivable apparemment.

      Si, cf
      http://subversion.apache.org/docs/release-notes/1.7.html#svnrdump

      • [^] # Re: Nouveautés ?

        Posté par  . Évalué à 1.

        Et ça:
        This hook script suffices to protect repositories from accidental use of svnrdump load. It does not (and cannot) protect the server from users who intentionally recompile svnrdump in order to bypass this restriction.

        • [^] # Re: Nouveautés ?

          Posté par  . Évalué à 2.

          Ben oui, mais dans ce cas-là il n'y a pas que svnrdump. Beaucoup d'outils de conversion (genre hgsubversion) utilisent probablement la même API, avec les mêmes risques.

      • [^] # Re: Nouveautés ?

        Posté par  . Évalué à 2.

        svnrdump fonctionne côté client, et semble utiliser le protocole existant. J'ai pu m'en servir pour dumper des repos depuis des serveurs certainement pas bleeding-edge.

  • # Pourquoi la section C/C++?

    Posté par  . Évalué à 10.

    Simple question, pourquoi la section de la news est C/C++ ?

    J'aurais plutôt vu une section "Gestion de versions" qui regrouperait les news CVS, SVN, Git, mercurial et leurs amis, mais elle n'existe pas: https://linuxfr.org/sections
    Ou alors une section "code" ou "programmation" plus générique?

    Sinon, dans "Communauté" ou "Technologie" peut être?

    A+

Suivre le flux des commentaires

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