Journal Git malgré moi

Posté par .
Tags : aucun
25
24
sept.
2010
Ça faisait un moment que je voulais regarder git, histoire de ne pas mourir idiot, et bien que je n'apprécie pas du tout les DVCS (j'y reviens). Mais bon, quand on voit que dès qu'un projet commence, une des premières requêtes est : "why not git?" si le projet utilise un bon vieux Subversion, je me dis que ça ne vaut pas le coup de perdre du temps à argumenter et démarrer directement par git (oui, les utilisateurs habituels de Subversion ayant tendance à être moins casse-couilles à ce sujet, je trouve). Donc voilà, je vais d'abord vous dire pourquoi je n'aime pas les DVCS (Distributed Version Control System), donc git en particulier, et au final, ce que j'aime dans git après avoir lu pas mal de tuto et fait quelques expériences.

Tout d'abord, je pense que les DVCS induisent un comportement malsain en terme de développement par rapport au VCS genre Subversion. C'est une thèse que je tiens depuis un moment (j'ai la flemme d'aller rechercher dans mes anciens commentaires mais j'ai déjà dû y faire allusion ici même). Pourquoi ? Version courte : parce qu'un DVCS favorise le travail solitaire isolé alors que ce comportement est techniquement banni d'office pour les VCS.

Version longue : je nuance. Il existe des workflows avec un DVCS qui ne sont pas très satisfaisants pour un développement open-source. Pouvoir cloner un dépôt et ensuite travailler en local sans même en rendre compte au mainteneur est pour moi une manière de faire très peu en adéquation avec un développement ouvert. Je ne dis pas que tout le monde fait ça, je dis que c'est un comportement possible. C'est un peu comme en C, on peut faire n'importe quoi, mais on peut aussi très bien s'en servir.

Et ce comportement tient à la nature décentralisée de l'outil, les DVCS fonctionne comme ça, on n'y peut absolument rien, c'est leur raison d'être. Alors après, oui, on peut très bien avoir un workflows plus ouvert, et les sites tels github ou gitorious aide aussi énormément à cela. Mais il suffit de voir la quantité de dépôt de petits projets qu'on peut trouver sur le web (les bidule.git posés sur un site web, voir ashd pour le dernier que j'ai croisé) : un développeur a fait son truc dans son coin, a publié son boulot sous forme d'un .git et l'abandonne au bon vouloir. Quelle différence avec un simple tarball sinon d'imposer le VCS ? Je pense que ça tient à la nature de l'outil utilisé qui favorise ce comportement individualiste.

Maintenant, certains me vanteront les avantages techniques, et me diront que c'est un super outil, toussa toussa. Mais ce que je veux dire là n'a rien de technique, c'est plus une raison philosophique qui me pousse à fuir les DVCS.

Mais bon, comme je l'ai dit, je ne veux pas mourir idiot et à l'occasion d'une idée de projet que je commence, je me suis dit : essayons. Alors, j'ai commencé à lire quelques tutoriels pour git, de qualité assez inégale. J'ai d'abord lu Git - SVN Crash Course qui permet à des gens habitués à SVN de se familiariser avec Git. Je dois dire que c'était assez obscur à la sortie et qu'il me restait plein de zones d'ombre sur la manière dont git fonctionne. J'ai jeté un oeil à gittutorial(7) mais je dois dire que j'ai vite abandonné, vu la rapidité des explications. J'ai continué avec Git Reference (écrit par les gars de github) et là, ça a éclairé ma lanterne mieux que tous les autres réunis. Je trouve les explications bien faites, progressive, didactique, avec des exemples simples mais éclairants. Donc je conseille ce dernier à tous ceux qui veulent s'y mettre.

Du coup, maintenant que j'ai une assez bonne idée de git et de son fonctionnement, voilà ce que je trouve sympa dans git. Tout d'abord, cette idée d'avoir une "staging area" (concept totalement inconnu dans SVN, lisez Git Reference pour comprendre ce que c'est) qui permet de sélectionner les fichiers à commiter et les autres. Je me suis retrouvé si souvent dans cette situation avec Subversion où je ne voulais commiter qu'une partie des fichiers modifiés et que je ne pouvais pas, à moins de pratiquer des acrobaties.

Ensuite, j'aime bien la manière de gérer les changements de nom de fichier comme n'étant justement pas un changement de nom (puisqu'en fait, ce ne sont pas les fichiers qui sont versionnés mais leur contenu). Je ne me suis pas risqué à faire quelques tests un peu tordus mais je me demande ce qu'il se passe si on a un gros fichier plein de code et qu'on le coupe en deux fichiers, est-ce que git est capable de repérer la source commune pour ces deux fichiers ? En tout cas, si c'est le cas, j'aime encore plus cette fonctionnalité.

Enfin, j'aime bien la gestion simplifié des branches et de les voir comme des contextes de travail plutôt que comme des trucs lourds auxquels on ne touche plus une fois que la branche est crée (rares sont les branches mergées dans Subversion, ça tient en partie à la difficulté technique de merger mais aussi au ressenti des développeurs avec l'utilisation des branches). Ici, avec git, pas de problème, on saute de branche en branche.

On sent bien qu'avec git, on peut procéder de 40 manières différentes pour le worflow. Je pense que c'est ce qui fait sa force. Mais sa faiblesse également selon moi. En tout cas, je vais continuer à l'utiliser pour mon projet, histoire de voir si à l'usage, ça marche. Jusqu'à présent, j'ai surtout essayé de comprendre le fonctionnement et je vais passer à l'utilisation dans un cas réel. Je reviendrai peut-être te revoir, cher journal, pour partager cette expérience.
  • # Mon ressentit

    Posté par . Évalué à  8 .

    parce qu'un DVCS favorise le travail solitaire isolé alors que ce comportement est techniquement banni d'office pour les VCS

    C'est fou mais mon ressenti depuis 2 ans que j'utilise mercurial c'est que c'est totalement le contraire.
    Je dirais même que l'un des problèmes du passage au DVCS c'est d'obliger ceux qui ont l'habitude de juste pousser bêtement à réfléchir pendant leur merge sur la place de leur code par rapport à celui des autres.

    Je trouve que les DVCS (mercurial dans mon experience) donne plus de visibilité sur le code des autres que les VCS (CVS SVN Clearcase dans mon experience).
    • [^] # Re: Mon ressentit

      Posté par . Évalué à  2 .

      Dans le cas d'un développement ouvert (cas des projets libres), on ne peut pas "juste pousser bêtement", enfin pas trop souvent. Du coup, on est obligé de discuter avant sur une liste par exemple ou sur IRC. Ça permet de savoir qui fait quoi, qui bosse sur quoi, qui va faire de grosses modifs, etc. Bref, du contact humain. Je trouve qu'on peut perdre cet aspect avec un DVCS, cet aspect social, hautement important dans le libre.
      • [^] # Re: Mon ressentit

        Posté par (page perso) . Évalué à  4 .

        Hum .. de mon éxpérience, pour la pluspart des projets utilisant git, pour envoyer tes patchs il faut justement les envoyer sur une ml pour en discutter, et pour qu'ils soient approuvés et mergés.

        Ton dépôt git perso ne sera qu'un dépôt de travail, le vrai dépôt important, c'est celui upstream.
        • [^] # Re: Mon ressentit

          Posté par (page perso) . Évalué à  4 .

          C'est juste, git ne permet normalement pas de pousser. Mais on peut faire des demandes de tirage.

          Je suis plutot un utilisateur de bazaar, mais ce que je trouve bien, c'est que le developeur peut bosser sur sa feature en commitant souvent (je commite frequemment) en local, puis une fois que c'est bien teste et bien fini, hop, on fait une demande de pull.

          Il faut bien voir que SVN n'a toujours pas de commits locaux, donc si on fait une connerie, on n'a plus qu'a revenir a la version du repo...
      • [^] # Re: Mon ressentit

        Posté par . Évalué à  4 .


        Ça permet de savoir qui fait quoi, qui bosse sur quoi, qui va faire de grosses modifs, etc.

        Ce n'est pas le rôle du VCS mais du bugtracker ou de la forge de faciliter cette communication.
        S'il est centralisé, on sait qui a pris quoi, à quoi est dédiée telle branche.

        J'entends souvent l'objection que tu évoques à savoir ce risque d'isolation qui fait que SVN colle si bien à l'intégration continue i.e à l'usage d'un branche unique.

        Et pourtant la CI n'est pas l'apanage des outils centralisés.
        Je te conseille cet excellent papier de Martin Fowler sur le sujet
        http://martinfowler.com/bliki/FeatureBranch.html

        En revanche, ce qui est sûr c'est qu'un outil comme SVN qui est incapable de supporter le "rename tracking" correctement (renommer un fichier différemment entre 2 branches perd l'historique de ce fichier lors du prochain merge entre ces 2 branches) ne peut supporter que l'integration continue et les branching par patch (une branche par patch que l'on tue une foi integrée).
        Pas de salut pour les autres branching patterns (1 branche par developpeur , une par lot de fonctionnalité en vue d'un développement parallèle de plusieurs équipes avec une phase d'intégration avant la livraison, ...)

        De là à dire que la mode de la CI n'existe que parce que SVN est déficient à la base, il n'y a qu'un pas.
  • # Mercurial.

    Posté par . Évalué à  8 .

    Salut,

    je ne connais pas git, mais j'utilise Mercurial avec un grand plaisir depuis quelques temps déjà.
    J'ai "compris" Mercurial grâce à ce petit tutoriel, qui pourrait t'aider aussi avec git, en sachant que les commandes ne sont pas les mêmes, mais que les fonctionnalités se recoupent.
    http://hginit.com/

    Et franchement, après quelques mois d'être passé de SVN à Mercurial, jamais jamais je ne reviendrai en arrière, tout est bien plus simple avec Mercurial, j'adore !

    Yth.
  • # Re: Git malgré moi

    Posté par . Évalué à  7 .

    Hello,

    Merci pour ce retour, très intéressant pour un utilisateur occasionnel (et grand fan) de git comme moi.

    La seconde partie, surtout, apporte des informations très intéressantes.

    Par contre sur la première partie, j'ai peur de ne pas être tout à fait d'accord avec toi.

    oui, les utilisateurs habituels de Subversion ayant tendance à être moins casse-couilles à ce sujet, je trouve Franchement ce n'est pas vraiment étonnant.

    Il est plus simple de dire "pourquoi tu commences avec SVN alors que tu peux avoir quelque chose de mille fois plus puissant et performant avec GIT ?" plutôt que "pourquoi tu veux utiliser GIT ? Utilise un truc qui fait moins de choses, parce que... heu parce que tu es habitué et parce que tout le monde a toujours fait comme ça" (argument de Windowsien quoi).

    On a beau être vendredi, je ne trolle qu'à moitié.

    Dans mon ancienne boite, où je militais activement (mais sans plus, je ne suis qu'administrateur système, pas développeur, c'est leur problème s'ils ne choisissent pas les bons outils) pour un passage de SVN à GIT, le lead dev m'a opposé un argument imparable : "Ouais, mais GIT, ce n'est pas très connu, je ne sais pas si on peu vraiment s'y fier, alors que SVN, ça a fait ses preuves sur des gros projets comme apache et ses millions de lignes de code". J'ai beaucoup rigolé, et je crois que je ne l'ai jamais dit pourquoi sa réflexion était ridicule.

    Version courte : parce qu'un DVCS favorise le travail solitaire isolé alors que ce comportement est techniquement banni d'office pour les VCS Je ne comprends pas bien l'argumentation là.

    Tu es en train de dire que l'utilisation d'un outil distribué va à l'encontre du partage ?

    On pourrait dire la même chose de la plupart des licences libres, copyleft ou pas. N'importe qui peut récupérer la source en local et ne pas contribuer upstream. Heureusement qu'on a l'aGPL, dans ce cas.

    Et puis je ne suis pas très à l'aise avec la thèse disant que les DVCS seraient "malsains" parce qu'ils offrent plus de liberté à l'utilisateur (dont, cette soit disant liberté d'être plus individualiste qu'avec SVN, ce dont je ne suis pas du tout convaincu).

    Pouvoir cloner un dépôt et ensuite travailler en local sans même en rendre compte au mainteneur est pour moi une manière de faire très peu en adéquation avec un développement ouvert. Et qu'est ce qui empêche de faire la même chose avec svn (un checkout et travailler en local ensuite) ?

    Et ce comportement tient à la nature décentralisée de l'outil, les DVCS fonctionne comme ça, on n'y peut absolument rien, c'est leur raison d'être. Non, la raison d'être, c'est de permettre de cloner un repo facilement. C'est la raison d'être du logiciel libre. Si c'est libre mais qu'en pratique on ne peut pas forker, à quoi sert la liberté ?

    En pratique, ça permet des choses comme les sous systèmes dans linux : Linus ne pull que parmi les branches de personnes de confiance, eux même prennent leurs commits depuis des personnes à qui ils délèguent leur confiance. On a ainsi une cathédrale de confiance redoutablement efficace.

    Mais il suffit de voir la quantité de dépôt de petits projets qu'on peut trouver sur le web (les bidule.git posés sur un site web, voir ashd pour le dernier que j'ai croisé) : un développeur a fait son truc dans son coin, a publié son boulot sous forme d'un .git et l'abandonne au bon vouloir. Quelle différence avec un simple tarball sinon d'imposer le VCS ? Je ne vois pas le rapport.

    Combien de projets "imposent" SVN en ne fournissant pas de tarball ? Combien de projets versionnés par SVN proposent de taper deux lignes pour récupérer les sources et aucun autre moyen de le faire ?

    En soi, ce n'est pas grave. Mais en entreprise, derrière certains firewalls fascistes, ça rend les choses très compliquées et c'est relativement frustrant.

    Bref, sur ce point là, GIT ou SVN, même combat. Dans les deux cas, rien n'empêche de fournir un tarball des sources sur un serveur http.

    Je pense que ça tient à la nature de l'outil utilisé qui favorise ce comportement individualiste. Je pense que tes conclusions sont un peu hatives :)

    (version édulcorée de "foutaises")


    Bonne continuation avec git. Vivement ton prochain feedback.
    • [^] # Re: Git malgré moi

      Posté par . Évalué à  2 .

      Je comprends bien tout ce que tu dis, et c'est généralement l'avis des fans de git que je trouve généralement en face de moi quand j'expose ma thèse. Donc, je ne vais pas continuer le troll. Juste apporter quelques précisions :
      - l'argument "c'est plus répandu donc c'est mieux", je le bannis directement, c'est un argument d'autorité, je suis un scientifique, on me convainct mieux avec des arguments scientifiques. Donc, là, je suis d'accord avec toi (et pas d'accord avec ton lead dev).
      - je ne dis pas qu'un outil distribué va à l'encontre du partage, je ne dis pas que c'est malsain, je dis que ça peut induire des comportements malsain. Tout comme le C peut induire des comportements de codage dangereux, ça ne veut pas dire que le C est dangereux ou que le C va à l'encontre de la sécurité. Tu vois ce que je veux dire ? Et c'est cette possibilité qui me chagrine et que je trouve assez absente des VCS. Mais après, je peux me tromper et avoir une mauvaise vision.
      - le workflow de Linux est certes exemplaire, mais ce n'est qu'un exemple de workflow parmi tout ceux proposés par git.


      Puisque je te tiens, je vais te poser une question purement pratique : quand créer une branche ? Parce que selon les tutos, il y a la méthode "je crée une branche par grosse fonctionnalité", ou alors "je crée une branche quand j'ai un développement qui va vraiment diverger". Quels sont les bonnes pratiques en la matière ?
      • [^] # Re: Git malgré moi

        Posté par (page perso) . Évalué à  4 .

        quand créer une branche ? Parce que selon les tutos, il y a la méthode "je crée une branche par grosse fonctionnalité", ou alors "je crée une branche quand j'ai un développement qui va vraiment diverger". Quels sont les bonnes pratiques en la matière ?

        Tu crée une branche quand tu clone.

        Ensuite, je travaille sur un bout de code. Si je l'ai fini, je le push sur master, sinon, il reste en attente en local (avec un push éventuel sur une branche distante "username-fonctionnalité" pour que les autres puissent voir ce que je fais.

        Si je n'ai pas fini cette fonctionnalité et que je dois travailler sur utre chose (par exemple j'ai besoin de corriger un bug, ou je pense à une toute autre fonctionnalité), alors je vais faire une branche locale supplémentaire du master distant. Et ainsi de suite.

        Donc, en pratique je fais une branche à chaque fois que je fais quelque chose de non trivial qui peut mettre du temps à finir ou mettre du temps à être accepté.
      • [^] # Re: Git malgré moi

        Posté par . Évalué à  8 .

        - je ne dis pas qu'un outil distribué va à l'encontre du partage, je ne dis pas que c'est malsain, je dis que ça peut induire des comportements malsain. [...] Tu vois ce que je veux dire ? Et c'est cette possibilité qui me chagrine et que je trouve assez absente des VCS. Mais après, je peux me tromper et avoir une mauvaise vision.

        Je ne me permettrais pas de dire que tu te trompes, ce serait pédant et subjectif. Mais je n'arrive vraiment pas à comprendre pourquoi tu considères que les DVCS permettent plus facilement de copier du code et de le conserver en local que ne le ferait SVN ou même un tarball.

        En quoi le fait que ça passe par git, svn, wget, scp rsync ou autre chose change la donne ?

        Mais après, je peux me tromper et avoir une mauvaise vision. Disons que nos visions divergent. Après dire qu'une vision est bonne ou mauvaise, le bien le mal, le manichéisme toussa, ça ne me semble pas pertinent dans un échange prolifique entre deux personnes sensées.

        le workflow de Linux est certes exemplaire, mais ce n'est qu'un exemple de workflow parmi tout ceux proposés par git

        C'est justement toute la beauté de git. Avec git, tu peux faire un workflow svn. Mais il en existe beaucoup d'autres.

        C'est aussi pour ça que j'aime git.


        Puisque je te tiens, je vais te poser une question purement pratique : quand créer une branche ?

        Bonne question :)

        Je me la suis également longtemps posée. Et comme je manque de créativité et que j'ai eu la chance de tomber sur un article[1] fort sympathique sur identica (via le groupe !git), je m'en suis inspiré.

        Le problème, c'est que c'est plutôt orienté pour les gros projets. Moi je ne suis qu'un petit développeur du dimanche (mais enthousiaste).

        Mais ce n'est pas tant un problème que ça. Il suffit de picorer dedans et de prendre ce qui est nécessaire ou pas. Du moins c'est comme ça que je procède.

        Selon le projet, je ne fais pas toujours de branches (autres que la principale bien sûr), parfois j'y ajoute juste une branche de développement. Parfois une branche pour une feature, si je sais que ça va mettre un certain nombre de temps à développer et que je ferais d'autre release entre temps.

        Bref, je pense que ce document peut servir de référence, qu'il est tout à fait adapté pour les gros projets, et adaptable pour les plus petits projets.

        C'est aussi ce qui peux expliquer que tu ait pu voir plusieurs méthodes différentes. Chacun a une expérience différente en fonction des projets différents. Mais je pense aussi (et je peux me tromper), que plus le projet grossit, plus le modèle de développement tend vers quelque chose de similaire, l'exemple le plus abouti étant Linux.

        En espérant que ça d'aide au moins un peu.

        [1] http://nvie.com/posts/a-successful-git-branching-model/


        (Bon j'ai encore pondu un roman. Désolé pour le paté, j'espère que je n'ai pas noyé les potentielles informations importantes dans le bruit).
        • [^] # Re: Git malgré moi

          Posté par . Évalué à  4 .

          Merci pour toutes ces indications et pour le lien.

          >> (Bon j'ai encore pondu un roman. Désolé pour le paté, j'espère que je n'ai pas noyé les potentielles informations importantes dans le bruit).

          Ça m'aurait ennuyé que tu répondes en 140 caractères...
        • [^] # Re: Git malgré moi

          Posté par . Évalué à  2 .

          Effectivement, ce modèle est assez complexe. Et personnellement, j'aurais inversé master et develop, c'est-à-dire que je ferais le développement dans master et que j'aurais une branche release. Et là me vient une question, est-ce que dans ce modèle, un tag ne suffirait-il pas ? Quelle est la nécessité d'avoir cette branche spécialement pour la release ? En fait, je me dis qu'un tag suffirait, et s'il y a besoin d'un hotfix, on crée une branche à ce moment là à partir du tag. Ça marche ça ?

          Sinon, ça donne des idées d'organisation. Merci beaucoup.

          La seule chose que je n'ai pas compris, c'est qu'il utilise --no-ff. Je vois vraiment pas l'intérêt. Est-ce qu'il ne perd pas toutes les micros étapes qu'il a fait dans la branche ? Du coup, quel intérêt de bien découper en micro étape (en plus, il insiste pour bien séparer) si tous les commits sont regroupés en un seul dans sa branche develop et qu'il supprime sa branche feature ? Bref, soit il y a qqch que je n'ai pas bien compris, soit il explique mal, soit il fait un truc idiot.
          • [^] # Re: Git malgré moi

            Posté par (page perso) . Évalué à  2 .

            --no-ff c'est pour forcer la création d'un commit de merge même quand il est inutile. Ça ne perd pas l'historique.

            DLFP >> PCInpact > Numerama >> LinuxFr.org

            • [^] # Re: Git malgré moi

              Posté par . Évalué à  2 .

              Ça veut dire que les diagrammes sont faux dans le billet du blog ?
              • [^] # Re: Git malgré moi

                Posté par (page perso) . Évalué à  2 .

                Non, ils sont très bien. La seule chose que force no-ff c'est la création d'un commit supplémentaire (c'est d'ailleurs ce qu'on voit dans le graphe). Et quand il dit "groups together", il veut juste dire que ça permet de savoir que ces commits sont apparus grâce à un merge.

                DLFP >> PCInpact > Numerama >> LinuxFr.org

                • [^] # Re: Git malgré moi

                  Posté par . Évalué à  3 .

                  D'accord, du coup, je ne suis pas trop d'accord avec l'argument de l'auteur qui consiste à dire que c'est mieux. Au final, oui on voit que ça a été développé dans une branche mais bon, est-ce qu'il y a un intérêt supérieur à ça ?
        • [^] # Re: Git malgré moi

          Posté par . Évalué à  3 .

          J'ai l'impression que votre différence d'appréciation provient de votre perspective.
          Celle de rewind est technique alors que la tienne est plus d'ordre organisationnel.

          Je m'explique:
          Avec SVN, l'approche basique consiste à travailler dans une branche unique partagée.
          Comme il n'y a a pas de clone du dépôt, chaque développeur prend en charge une demande de changement, la réalise et la remet dès qu'elle est traitée.
          Au pire, il doit effectuer un merge avant de remettre mais il reste proche du développement principal.

          Avec un DVCS (Bazaar et svk exceptés car il supportent les 2 modes), chaque développeur dispose de sa propre branche et il n'est pas possible de bosser sur une branche partagée (Avec Git et Hg, il me semble qu'il existe des mécanismes qui permettent de commiter et pusher dans la même transaction en contactant le dépôt principal mais ce n'est pas le workflow de base).
          En revanche, il est naturel de prendre en charge plusieurs demandes à la suite et de le commiter dans sa propre branche en local sans être obligé de les reporter directement sur la branche principale.
          De ce fait, puisque plusieurs changesets peuvent s'enchaîner sans réel besoin de les reporter sur le tronc, le développeur peut être tenté de s'isoler, ce qui occasionnera inévitablement un travail plus important à moment de l'intégration.

          Pour appliquer cette stratégie avec SVN, il est nécessaire de créer explicitement une branche par développeur. Mais ceci n'est pas automatique et surtout, le fait que SVN ne supporte pas le rename tracking décourage fortement cette pratique dès qu'on fait un peu de refactoring (renommage de package par exemple). Le merge n'est pas automatique et il faut relancer le refactoring à la main dans la branche principale.

          En revanche, d'un point de vue organisationnel les DVCS sont plus ouverts aux contributions en ce sens qu'ils n'obligent pas à se faire reconnaitre pour participer sur un projet.
          Avec SVN, il faut accorder des droits en écriture sur le repository pour accueillir de nouveaux participants (hormis l'échange de diff/patch qui contourne le VCS) . Cet accès permet au contributeur d'accéder directement à la branche principale avec les risques qui s'ensuivent et un accès limité à une branche dédiée est plus complexe à mettre en oeuvre.
          Avec un DVCS il suffit de cloner le repository et on peut commencer à bosser dans sa propre branche. Les développeurs du projet n'ont qu'à puller les changements dans leur propre dépôt local, merger les patchs qui les intéressent et remonter dans le dépôt principal sans besoin d'octroyer de droits sur ce dépôt. Ce n'est que lorsque le contributeur a fait ses preuves qu'il obtient ce privilège de pusher directement sur le dépôt central.

          Ce workflow est plus complexe mais plus souple.
          C'est la raison pour laquelle je considère que les DVCS se prêtent mieux aux projets communautaires alors que SVN de par sa simplicité et sa gestion centralisée des droits se prête mieux au monde l'entreprise.

          Voilà je crains avoir encore plus délayé que toi.
          • [^] # Re: Git malgré moi

            Posté par . Évalué à  1 .

            Pour en remettre une couche sur le rename tracking voici une description
            du problème:
            http://subversion.tigris.org/issues/show_bug.cgi?id=898

            Etant donné que SVN utilise svn cp pour brancher et ne fait sémantiquement pas la différence entre une branche et une simple copie d'arbo ce problème n'est pas près d'être résolu. Les branches sont des objets à part entières dans Git

            Quelque commentaires:



            """
            Moving to 1.4, since, while cmpilato has started this work on the fs-atomic-
            renames branch, it won't be merged before 1.3.
            ...
            Post-1.6 issue sweep. Since 1.7 is already shaping up to be a large release,
            move to 1.8-consider.
            ...
            Seems like this thing is going to be pushed out indefinitely.
            """


            Ce bug a été ouvert en 2002 et il est reporté aux calendes grecques.
            Nous en sommes à la 1.6.12.
            Bonne chance les gars
      • [^] # Re: Git malgré moi

        Posté par (page perso) . Évalué à  1 .

        Puisque je te tiens, je vais te poser une question purement pratique : quand créer une branche ? Parce que selon les tutos, il y a la méthode "je crée une branche par grosse fonctionnalité", ou alors "je crée une branche quand j'ai un développement qui va vraiment diverger". Quels sont les bonnes pratiques en la matière ?

        Je crée une branche tout le temps. Aucun commit ne se fait directement dans master. Les commits qui sont sur master sont ceux qui ont été relu par un autre membre de l'équipe de développement. Si j'ai un mini patch de quelques lignes, ça se passe comme ça:
        - je mets le commit dans une branche publique nommée "typo" ou qqch comme ça
        - je demande une relecture sur IRC
        - on me repond "ok"
        - je merge dans master

        Que ce soit juste un mini patch ou une branche contenant des dizaines de patches, le processus revient au même. Bien sûr, il est plus facile de trouver quelqu'un pour relire la branche quand la branche ne contient pas 100 patches non-nettoyés (c'est à dire que des commits contiennent des "printf" temporaires de debug). Il est d'usage de découper la branche en patches par fonctionnalité avant de la proposer à la relecture.

        Ça c'est pour les branches publiques qu'on propose à la relecture. Ensuite, j'ai des branches privées temporaires, lorsque je rebase (git-rebase roxor), j'expérimente quelque chose qui n'aboutit à rien. Dans ce cas, comment j'organise mon travail n'est pas très important. Tout comme si j'utilise emacs, gedit ou vim n'a pas d'importance sur le projet.
  • # DVCS RoXoRise des Ours !

    Posté par (page perso) . Évalué à  2 .

    Ceci est dit.

    GIT permet de travailler en mode cvs ou subversion si tu le désires, donc, je ne comprends pas vraiment la critique.

    Mais il y a des plus non négligeables. Par exemple, j'ai l'habitude de ne pas commiter un code qui ne fonctionne pas ou implémente une partie non suffisament aboutie. Dans ce cas, j'aime néanmoins avoir un historique pour mon usage personnel. J'aime également pouvoir créer des branches qui ne sont d'utilité que pour moi-même pour expérimenter. Git me l'offre.
  • # Git svn

    Posté par (page perso) . Évalué à  5 .

    Pour la puissance de Git tout en gardant svn, tu peux toujours utiliser git-svn.

    « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

    • [^] # Re: Git svn

      Posté par . Évalué à  2 .

      Je connaissais son existence mais là, l'idée, c'est de passer en 100% git, sinon ça va gâcher le plaisir...
    • [^] # Re: Git svn

      Posté par . Évalué à  2 .

      Mais justement, qu'est-ce tu gardes de SVN?
      • [^] # Re: Git svn

        Posté par . Évalué à  3 .

        Tout.

        Tu as la puissance de git en local tout en ayant la possibilité de garder ton repo SVN et donc n'avoir rien à changer dans tes confs et pour les autres. C'est très très très pratique quand tu es dans une infrastructure assez lourde et que tu ne peux pas changer de SCM facilement (Au choix problème de gestion, management, technique, formation des autres devs, manque d'outils etc.).

        Tout les devs avec qui j'ai bossé et qui ont essayé ne peuvent plus s'en passer tellement ca leur facilite la vie. Pourtant ils étaient tous sceptiques.
        Workflow commun:
        - Ton master local correspond au trunk/
        - Possibilité de mapper des branches locales vers des branches subversion. On créé une branche par feature. Tout ceux qui bossent sur cette feature utilise cette branche. On peut donc bosser sur une feature que les autres devs utilisent git ou pas
        - Pour les petits patchs solo, une branche locale (aussi rattachée au trunk) un dcommit et c'est poussé dans le trunk.

        Après ca reste git, compliqué d'accès. Trop de choix et de facon de faire. Marrant presque aucuns de ceux qui utilise git-svn ne l'utilisent de la même facon (merge puis dcommit VS dcommit, rebase VS merge, suivi de branch). Bref chacun fait a sa sauce, ce qui implique de perdre pas mal de temps au départ et n'aide pas à son adoption.

        Bref c'est l'outil idéal si comme contrainte tu as "Le dépot du projet sur lequel je bosse est SVN". Attention j'ai pas dit que c'était l'outil idéal ;-)
        • [^] # Re: Git svn

          Posté par . Évalué à  0 .

          J'ai pas tout compris.

          - Ton master local correspond au trunk/
          ça ok

          - Possibilité de mapper des branches locales vers des branches subversion.
          L'intérêt? Pourquoi ne pas fait directement une branche dans svn?

          On créé une branche par feature.
          C'est pas un peu abusé du concept, juste un point de vue.

          Tout ceux qui bossent sur cette feature utilise cette branche. On peut donc bosser sur une feature que les autres devs utilisent git ou pas

          Encore une fois, qu'est-ce qui empêche de créer une branche svn à part?
          À te lire, on a l'impression que les autres devs n'y ont pas accès

          Et le "merge" tu le fais où et quand? Sachant que c'est(c'était?) un inconvénient de SVN.
          Tu fais ton "merge" dans GIT et tu synchronises ensuite dans le tronc SVN?

          Les revisions SVN sont donc beaucoup plus espacées, ça se passe comment si tu veu revoir l'évolution de telle partie de code?
          • [^] # Re: Git svn

            Posté par . Évalué à  3 .

            > L'intérêt? Pourquoi ne pas fait directement une branche dans svn?

            En fait c'est mal exprimé en effet. Tu crée ta branche subversion et tu peux associé N de tes branches git à cette branche subversion. En général une seule suffit, mais des fois c'est pratique d'en faire deux. Pour bosser sur des trucs séparés qui iront dans la même branche SVN. Évidement l'intêret de la branche SVN, c'est que les gens qui utilisent SVN peuvent y avoir accès.
            Note que tu gardes le côté pratique de git, par ce qu'un commit git n'entraine pas immédiatement un commit SVN. Tu décides quand les pousser.

            > C'est pas un peu abusé du concept, juste un point de vue.

            C'est un point de vue en effet. Libre à chacun de faire comme il le veut. L'expérience m'a montré que mettre de nouveaux devs ou des refactoring important dans le trunk était une très mauvaise idée. Tu te retrouves avec un trunk non stable, ou avec des fonctionalités que tu ne veux pas encore ds la branche officielle donc impossibilité de releaser (voir même souvent de rollbacker). Avoir une branche par feature ca permet de prendre son temps pour que tout arrive à maturation, et de réfléchir au moment où tu intègres dans la branche principale. Ne pas créer de branche, ca veut dire que quelqu'un bosse en sousmarin donc tu n'as aucune idée de son changeset. C'est une question d'équilibre c'est sur. Il n'y a pas de bonne solution, il y a des solutions qui fonctionne avec ton projet et ton équipe.

            > À te lire, on a l'impression que les autres devs n'y ont pas accès

            Si bien sur, c'est une branche SVN. Ce que t'apporte git-svn, ce sont les branches locales et la possibilité créer une ou plusieurs branches git à partir d'une branche SVN. Tu travailles en locale avec tes branches git. Et tu pousses tes commits sur le SVN en une commande, de même tu mets à jour en une commande. Bref tu as la puissance de git sur la gestion des branches, des merges, des cherry-pick, du stash etc. tout en utilisant très simplement SVN. Hormis 2 ou 3 pièges ca fonctionne très bien, j'ai jamais réussi à le planter.

            > Et le "merge" tu le fais où et quand? Sachant que c'est(c'était?) un inconvénient de SVN.

            Oui c'est un des gros interet de passer à git-svn. Les merge (ou rebase) sont fait par git. Ensuite tu pousses le résultat sur le SVN. L'inconvéniant c'est que à cause du backend SVN tu perds les informations de merge dans git une fois que c'est poussé. Y'a pas de miracle.

            > Les revisions SVN sont donc beaucoup plus espacées, ça se passe comment si tu veu revoir l'évolution de telle partie de code?

            La j'ai pas compris la question.

            Pour résumé comme dit plus haut. git-svn c'est le meilleur client svn, même si tu veux pas merger.
          • [^] # Re: Git svn

            Posté par (page perso) . Évalué à  1 .

            - Possibilité de mapper des branches locales vers des branches subversion.
            L'intérêt? Pourquoi ne pas fait directement une branche dans svn?


            Quand je développe une nouvelle fonctionnalité non triviale (disons 5 patches), je n'écris pas directement les 5 patches du premier coup directement sans erreur. J'expérimente quelque chose, je me rends compte que ce que j'écris n'est pas la meilleur solution, je change en cours de route. Je teste, il y a un bug dans le deuxième patch, je le corrige. Bref, pendant ce processus, j'ai besoin de modifier le deuxième patch sur les 5 commits en local. Puis je me rends compte que le troisième patch contient des debugs que je ne voulais pas commiter, et une faute de grammaire dans les commentaires. Je corrige. Ensuite, je propose mes 5 patches propres à la relecture, ils sont approuvés, puis inclus dans master.

            Si j'avais fait tout cela avec svn, j'aurais eu deux possibilités:
            - soit je propose un seul patch contenant l'équivalent de mes 5 patches. Ça va être plus difficile au relecteur de comprendre et d'être sûr qu'il n'y a pas d'erreur car on perd le découpage en patches élémentaires.
            - soit je commit au fur et à mesure mes patches dans la branche svn. Mais toujours pareil, le relecteur doit se taper les erreurs de développement. Ça lui fait du travail supplémentaire. Le temps du relecteur n'est pas une ressource illimité, il risque de ne pas avoir le temps et de ne pas accepter mon travail.

            Et puis personnellement, même si je propose un seul patch sur svn, git reste un bon outil pour moi pour conserver mes patches d'expérimentation, y revenir, etc. On ne peut pas faire ça avec svn. Quilt est pas mal pour ça, mais l'interface de git est tout de même meilleure et plus simple.
  • # staging area

    Posté par . Évalué à  4 .

    Je me suis retrouvé si souvent dans cette situation avec Subversion où je ne voulais commiter qu'une partie des fichiers modifiés et que je ne pouvais pas, à moins de pratiquer des acrobaties.

    Il suffit de passer explicitement la liste des fichiers (ou des répertoires) derrière "svn ci". Loin de moi l'idée de défendre SVN en général face aux DVCS, mais ici je ne vois pas où est l'acrobatie ni la difficulté.
    • [^] # Re: staging area

      Posté par (page perso) . Évalué à  3 .

      Pour n'envoyer qu'une partie des modifications faites sur un fichier avec svn ce n'est pas forcément simple. Tu peux toujours générer ton patch, l'éditer et le réappliquer mais bon... par rapport à un bon git add -p, ce n'est pas très efficace.
      • [^] # Re: staging area

        Posté par (page perso) . Évalué à  3 .

        Encore mieux, git gui te permet de graphiquement choisir les lignes que tu veux commiter et celles que tu ne veux pas commiter.
    • [^] # Re: staging area

      Posté par . Évalué à  2 .

      Sauf quand la liste des fichiers est super longue... Un exemple tout bête : le refactoring. Tu bosse sur un truc et là, tu t'aperçois qu'il faut refactorer et que ça touche plein de fichiers. Mais tu aimerais envoyer le commit du refactoring tout seul, mais tu as déjà modifié d'autres fichiers. Là, pas de solution, généralement, ça finit en commit qui inclus deux trucs qui n'ont rien à voir.
      • [^] # Re: staging area

        Posté par (page perso) . Évalué à  1 .

        Ou alors tu fais ton commit avec comme message "temp"
        tu fais ton refactoring avec comme message "refactoring"
        tu finis ta fonctionnalité "temp2"

        et tu fais un rebase intéractif: git rebase -i HEAD~5

        tu déplace tes commits pour avoir:

        pick refactoring
        pick temp1
        squash temp2

        Les deux derniers commits seront fusionnés et on te demandera le nouveau message de commit.

        http://book.git-scm.com/4_interactive_rebasing.html
      • [^] # Re: staging area

        Posté par . Évalué à  2 .

        Je ne suis pas sûr de bien comprendre, mais connais-tu les changelists ?
        http://svnbook.red-bean.com/en/1.5/svn.advanced.changelists.(...)

        Ceci permet de regrouper les changements à commiter.
        Le mécanisme n'est pas aussi puissant que la mise en place de branches dédiées (inhérent aux DVCS) qui permet de commiter les changements de manière unitaire puis de reporter ceux que l'on souhaite sur le tronc (cherry-picking). D'ailleurs, si quelqu'un a déjà pu utiliser le cherry-picking correctement avec SVN, je suis preneur pour un retour d'expérience.
        • [^] # Re: staging area

          Posté par . Évalué à  2 .

          Je vais te faire la réponse que j'ai lue quelque part à propos d'un autre sujet : c'est dans la partie advanced topics (autant dire que personne ne le lit, et moi le premier, je n'avais jamais entendu parler de ça, ça n'apparaît dans aucun tutos SVN). Je l'ai lu sur les branches, qui sont considérées comme un fonctionnement normal dans git et comme un truc avancé dans SVN. Ici, la staging area, c'est sur la deuxième page de Git Reference (la première page, c'est git init et git clone, autant dire pas grand chose).
          • [^] # Re: staging area

            Posté par . Évalué à  3 .

            Désolé, j'ai rien compris à ce que tu voulais expliquer.
            • [^] # Re: staging area

              Posté par . Évalué à  4 .

              Je reprends alors. D'un côté, tu as SVN qui peut faire des branches et des merges, et qui peut faire des changelists. Mais ces deux fonctionnalités sont considérés comme avancés (dans le svn book, elles sont dans un chapitre très éloigné du début) et personne ne les utilise, soit par peur ("c'est avancé, donc ça doit être dur"), soit par méconnaissance ("je ne lis pas les chapitres sur les utilisations avancés, j'en aurai pas besoin"). De l'autre côté, tu as git, qui peut faire des branches et des merges, et qui a une staging area qui permet plein de choses (dont l'équivalent des changelists). Là, ces deux fonctionnalités sont considérés comme basiques et apparaissent dans tous les turoriels, souvent au tout début pour la staging area. Donc les gens l'utilisent parce qu'ils connaissent ces fonctionnalités et qu'ils considèrent qu'elles font partie des fonctionnalités de base (donc faciles).
              • [^] # Re: staging area

                Posté par . Évalué à  2 .

                Simplement parce que le branching avec SVN est bloated. Une usine à gaz a été créé pour pallier les défauts d'architecture que j'ai exposé un peu plus loin.
                Cette belle idée au départ de pouvoir brancher à plat directement dans l'arborescence couplée avec cette notion de révisions qui simule des "liens symboliques" et qui pointe que sur les fichiers modifiés depuis la dernière révision était séduisante. (branche et tags en O(n)). L'équipe SVN s'était dit qu'ils s'occuperaient des branches plus tard (mémoire de merge, rename tracking, pas de merge cycliques, ... par exemple) et dans les faits c'est tout qui est à revoir. (pour le rename tracking il faut des identifiants d'objet alors qu'on a que des révsions ou un DAG+notion de branche pour être efficace). Leur modèle se complique (mergeinfo qu'il faut supprimer à la main, révisions à indiquer explicitement parce la mémoire de merge est défaillante, option reintegrate pour traiter les branches de patch, ...) Ils sont dans une impasse ... Ca explique pourquoi on trouve ca dans la section advanced.

                http://blogs.open.collab.net/svn/2008/07/subversion-merg.htm(...)

                Du coup on conseille de bosser dans une branche et on promeut l'intégration continue puisqu'on ne sait traiter que ça.
      • [^] # Re: staging area

        Posté par . Évalué à  1 .

        tu t'aperçois qu'il faut refactorer et que ça touche plein de fichiers. Mais tu aimerais envoyer le commit du refactoring tout seul, mais tu as déjà modifié d'autres fichiers.

        svn di > travailencours.patch
        svn revert -R .
        # faire le refactoring
        svn ci -m "Refactoring"
        patch -p0 < travailencours.patch
        # reprendre le travail précédent
  • # Un bon VCS est un DVCS

    Posté par (page perso) . Évalué à  6 .

    Un bon outil de gestion de version est forcément distribué, tout simplement parce qu'on ne peut pas faire de gestion de version complète en équipe de façon seulement centralisée.

    En effet, lorsqu'on modifie des documents, avec un VCS décentralisé, on a le choix entre :
    — commiter au fur et à mesure, donc des versions non fonctionnelles ;
    — ne commiter que lorsqu'on a fini chaque travail, donc des versions censées être fonctionnelles.

    La première solution est une mauvaise idée dans le cadre d'un travail en équipe. La seconde solution revient à travailler sans filet entre chaque étape, et amène souvent à gérer son travail avec le bon vieux outil de gestion de version cp-old (cp fichier fichier.old). Ce qui, quand on dispose d'un vrai outil de gestion de version, est quand même un comble !
    • [^] # Re: Un bon VCS est un DVCS

      Posté par (page perso) . Évalué à  2 .

      C'est là qu'intervient toute la puissance de git : je commite au fur et à mesure et quand j'ai fini mon boulot, je sort le rebase interactif et je réarange mes commits comme je veux.

      Après, il y a des outils comme quilt out stgit qui permettent de faciliter ce fonctionnement encore plus.
    • [^] # Re: Un bon VCS est un DVCS

      Posté par . Évalué à  -1 .

      3ieme option: appliquer un development agile, travailler sur de petites unites de fonctionalites ce qui permet de commiter au fur et a mesure tout en ayant constamment un build fonctionnel tous les soirs.

      Après, ca veut pas dire que les dvcs n'ont pas leur gros avantages sur les centralises, mais on peut tout a fait s'en sortir avec svn. C'est juste plus chiant dans certains cas.

      If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

    • [^] # Re: Un bon VCS est un DVCS

      Posté par (page perso) . Évalué à  2 .

      J'ai constaté quand même des inconvénients au principe du DVCS. Dans une petite équipe, avec svn et les mails de commits, on sait assez bien ce qui se passe.

      Avec un DVCS, les membres ont tendance à garder pour eux leurs développement en cours, et à faire des push moins souvent qu'ils ne faisaient de commits. Du coup, on a des périodes où tout le monde bosse sur un truc, mais ce n'est pas visible sur le dépot principal.
      • [^] # Re: Un bon VCS est un DVCS

        Posté par (page perso) . Évalué à  4 .

        Et qu'est-ce qui t'empêche de puller leur repos personnels ?
      • [^] # Re: Un bon VCS est un DVCS

        Posté par . Évalué à  1 .

        Ça me rassure de voir que le comportement que je décris peut arriver dans certains cas (heureusement, pas tous). J'espère que ça réussira à convaincre ceux qui m'affirment que non, non, non c'est toujours mieux avec git que, ben pas forcément.
  • # workflows

    Posté par (page perso) . Évalué à  3 .

    > Pouvoir cloner un dépôt et ensuite travailler en local sans même en rendre compte au
    > mainteneur est pour moi une manière de faire très peu en adéquation avec un
    > développement ouvert.

    Tu proposes quoi comme alternative avec un VCS centralisé ? J'en vois deux :

    1) Je veux contribuer à un projet, je commence par demander les droits pour commiter sur le dépôt du projet. Une fois que j'aurais cette autorisation, je pourrais faire mes commits là bas.

    2) Je veux contribuer à un projet, je n'ai pas les droits. Je fais un "svn checkout", je code, je fais "svn diff" et j'envoie le résultat par email.

    Pour la version 1), je ne sais pas si ça t'es déjà arrivé d'être autorisé à commiter sur le SVN d'un projet avant d'avoir fait tes preuves avec du code, mais perso, ça ne m'est jamais arrivé, même en rêve. Maintenant, admettons que ça arrive. Cool, je peux commiter sur le dépôt, je n'ai même pas besoin de parler du code sur la mailing-list avant de commiter. C'est plutôt un handicap pour le côté communautaire, non, de pouvoir commiter sans discuter ?

    Reste la solution 2), et c'est justement là qu'un DVCS est infiniment plus puissant/pratique, puisque tu peux faire tes commits en local, donc gérer assez facilement plusieurs patchs (y compris si les patchs dépendent les uns des autres).

    Le fait qu'on puisse cloner un dépôt est justement quelque chose qui force un fonctionnement communautaire. Avec un VCS centralisé, tu as en général une short-list de gens qui ont les droits pour les commits, et le fait que techniquement ils aient ce droit leur donne un très grand pouvoir de décision. Les gens qui ne sont pas sur la short-list sont mis à l'écart. Avec un DVCS, tu peux aussi avoir un petit nombre de gens qui ont accès au dépôt de référence (éventuellement, ce petit nombre peut être 1), mais si ils abusent de leur pouvoir, les autres contributeurs peuvent continuer à travailler et à s'organiser. Un corolaire est que les mainteneurs n'abusent pas de leurs pouvoir pour les projets gérés par un DVCS.

    > Mais il suffit de voir la quantité de dépôt de petits projets qu'on peut trouver sur le web
    > (les bidule.git posés sur un site web, voir ashd pour le dernier que j'ai croisé) : un
    > développeur a fait son truc dans son coin, a publié son boulot sous forme d'un .git et
    > l'abandonne au bon vouloir.

    Quelle différence avec un SVN accessible en lecture seule, publié et abandonné au bon vouloir ?
    • [^] # Re: workflows

      Posté par . Évalué à  3 .


      >1) Je veux contribuer à un projet, je commence par demander les droits pour commiter sur le dépôt du projet. Une fois que j'aurais cette autorisation, je pourrais faire mes commits là bas.
      >2) Je veux contribuer à un projet, je n'ai pas les droits. Je fais un "svn checkout", je code, je fais "svn diff" et j'envoie le résultat par email.


      3) Je sais configurer mon VCS, alors je donne les droits d'écriture aux wannabes qui le demande uniquement sur une branche qui leur est dédiée. Comme ca je peux voir leur travail en cours de route et les aider. Et c'est moi qui merge leurs commits dans les branches de prod.
      • [^] # Re: workflows

        Posté par (page perso) . Évalué à  2 .

        En vrai, ça t'est déjà arrivé de donner les droits sur une branche à quelqu'un que tu ne connaissait pas et qui n'avait pas encore envoyé de code ?

        Moi, ce que je vois autour de moi, c'est qu'il faut galérer à envoyer des patchs avec un outil qui le fait mal pendant un moment avant d'avoir ça.
        • [^] # Re: workflows

          Posté par . Évalué à  2 .

          C'est ce qu'on fait au boulot avec les nouveaux arrivant et les gens qui n'ont pas de raison d'intégrer du code eux même. Techniquement y'aurait pas de soucis pour le faire sur des projets communautaires.

          Je crois que dans le libre, les gens préfèrent leur confort et leurs convictions à aider les autres à intégrer un projet. On essaye encore de te convaincre sur quel éditeur utiliser en 2010... ;) Mais y'a des projets très sympas où le maintainer est très acceuillant pour ceux qui cherchent à contribuer. Récuperer un commit bit sur hudson c'est pas trop compliqué par exemple.
          • [^] # Re: workflows

            Posté par . Évalué à  2 .

            Oui enfin le merge avec svn est quand même une horreur contrairement à git qui
            gère ça très bien.

            Par exemple avec svn si tu ne notes pas les commits que t'as mergé de telle ou
            telle branche tu ne t'en sors pas.
    • [^] # Re: workflows

      Posté par . Évalué à  3 .

      C'est bien, tu décris exactement le comportement que je désapprouve dans mon argumentaire : le gars qui forke dans son coin sans rien dire au mainteneur. Les projets qui ouvrent leur dépôt ne sont pas si rares. Si on regarde KDE, qui n'est pas un petit projet, il me semble que les conditions pour avoir un accès au SVN ne sont pas si terrible [1], ça implique seulement de se conformer à une politique de commit, mais le compte SVN en lui-même n'est pas difficile à avoir.

      [1] http://developer.kde.org/documentation/other/developer-faq.h(...)
      • [^] # Re: workflows

        Posté par (page perso) . Évalué à  2 .

        Dans le lien que tu donnes, je trouve :

        If you are contributing to an application that is not yours, it is a good idea to first submitting your coding as patches to the author and let him apply them.

        Maintenant, faudrait que tu nous expliques ce que tu entends par « forker dans son coin ». Ce que permet un DVCS, c'est d'avoir des branches qui sont hébergées ailleurs que sur le dépôt principal. Ça change quoi que mes branches soient hébergées sur mon site perso, sur github, ou dans l'archive du projet ? Ce qui est important, c'est de savoir quel code est dans la branche principale (i.e. le trunk sous SVN), mais imposer à tout le monde d'héberger ses branches au même endroit, je vois pas l'intérêt.

        Ce qui fait que les gens poussent d'une manière ou d'une autre leur code en upstream, ce n'est pas l'outil, c'est pour les 1001 raisons qui font que l'open-source marche. La gloire d'avoir du code à soi en upstream, le fait de ne pas avoir à maintenir une branch séparée longtemps, ...

        Avec SVN, tu peux forker sans problème. svnsync par exemple te permet même de récupérer l'historique. Côté « fork », les VCS sont à peu près tous à égalité. Le problème, c'est le merge qui peut suivre le fork.

        Ce qui est marrant, c'est qu'ailleurs, tu dis que le workflow de Linux est exemplaire, et justement, le workflow de Linux, c'est exactement ce que tu as l'air de critiquer ici.
        • [^] # Re: workflows

          Posté par . Évalué à  3 .

          Tout d'abord, on se calme hein, pas la peine d'être aussi agressif.

          Ensuite, dans la phrase que tu cites, il y a exactement ce que je décris dans mon texte initial : avec un VCS, le gars qui fait des modifs est obligé de discuter avec upstream, il est obligé de s'intégrer socialement avec le projet, il est obligé de collaborer s'il veut que ses modifs soient intégrées, parce qu'il est relativement difficile de maintenir un patch en dehors de la "branche principale" (parce que justement, ce n'est pas fait pour ça). Alors qu'un DVCS, tu peux avoir ton fork sur ton site, sans en parler à upstream. Ce que ça change (puisque c'est ta question), c'est que dans un cas, tu as une obligation technique de collaborer, dans l'autre cas, tu as une permission technique de ne pas collaborer. Et ma thèse, c'est que ça peut engendrer des comportements idoines, en ce sens qu'avec un DVCS, tu peux faire ton égoiste dans ton coin, chose impossible avec un VCS. Et j'insiste bien sur "peux", parce qu'effectivement, on peut faire autrement aussi et ça se passe bien dans la plupart des cas (heureusement).

          Quant à Linux, ce n'est pas un workflow où chacun garde tout dans son coin sur son site, c'est un workflow assez complexe et très hiérarchique où tout est public, au vu et au su de tous. Donc ça ne rentre vraiment pas dans le comportement que je critique. Et d'ailleurs, ceux qui s'y essaient dans le développement de Linux se font taper sur les doigts (comme Google récemment). Ce qui n'est pas imposé par le VCS l'est par la communauté. Il n'y a qu'à voir la procédure d'acception des patchs où un des premiers trucs qui est dit est : en parler sur la LKML, c'est à dire s'intégrer socialement avec le projet, et la boucle est bouclée.
  • # Les DVCS encouragent le travail collaboratif

    Posté par . Évalué à  3 .

    Un VCS c'est avant tout un outil de travail, son boulot c'est de conserver un historique des modifications, et de faciliter le travail collaboratif (détecter les conflits voire les résoudre pour les plus triviaux).

    Un DVCS permet le travail hors-ligne (le développeur a toujours accès à l'historique, peut commiter les modifications ==> gros avantage pour le travail collaboratif), des opérations beaucoup plus rapides car moins d'accès réseau, pour un outil aussi utilisé qu'un VCS c'est très important. La gestion des branches permet aux développeurs d'expérimenter plus facilement sans perturber le développement de la branche principale, de gérer différentes versions d'un même logiciel plus facilement (avec le cherry-picking/transplant, porter un bugfix deviendrait presque trivial), l'outillage de merge plus puissant de git/hg & cie facilite encore la vie des développeurs.
    Sans oublier la souplesse des DVCS qui facilitent leur intégration dans les workflows (et notamment les outils de revue, la possibilité d'importer/exporter des patchs via mail sans perdre l'historique etc ...).

    ===> Git ou mercurial sont de bien meilleurs VCS que ne le sont CVS ou svn (et comme j'aime le répéter le meilleur client subversion s'appelle git ;-) )

    Rien n'est plus faux que d'affirmer qu'un DVCS encourage le travail isolé, je dirais que c'est même le contraire. Par rapport à CVS (et dans une moindre mesure svn), git/hg permettent de s'abstraire des défauts de ces outils (accès réseau obligatoire, lenteurs, merge pourri, gestion des branches complexes, outils fragiles).
    • [^] # Re: Les DVCS encouragent le travail collaboratif

      Posté par . Évalué à  3 .


      L'outillage de merge plus puissant de git/hg & cie facilite encore la vie des développeurs.


      Je ne suis pas certain que la puissance des merges découle de la nature centralisée ou non des VCS.

      SVN ne gère pas les merges correctement simplement parce qu'il ne sait pas faire la différence entre une branche et une recopie ce qui mène à plein de cas tordus.
      Ajoute à ca que le stockage correspond à une séquence linéaire de révisions. Pour un merge, ceci oblige à parcourir toutes les révisions une par une même celles qui ne concernent pas les fichiers des arbos à merger.

      Clearcase ou Perforce, bien que centralisés, prennent très bien en charge les merges même si le stockage s'effectue au niveau des répertoires et des fichiers. Ce sont des objets avec un identifiant et un historique unique. Les merge 3 ways sont sûrs et les merge d'arborescences sont relativement aussi même s'ils sont bien plus lents car il necessite de descndre recursivement dans l'arboresence et de traiter les fichiers/répertoires un par un.

      La puissance des DVCS type git, hg ou monotone vient du fait qu'ils stockent les révisions qui se succèdent ou qui forkent sous forme de graphes (DAGs) et que les branches sont des objets de première classe. Il est donc aisé de déterminer quelles révisions sont concernées par un merge.
      Cette évolution est intervenue plus tard dans l'histoire des VCS, mais on pourrait très bien imaginer qu'un nouvel outil centralisé adopte une architecture identique. Seulement, à quoi servirait de créer un nouveau VCS centralisé sur cette base alors que les DVCS sont supérieurs sur tant d'autres aspects et qu'ils proposent toutes les fonctionnalités des VCS (à l'exception du verrou pessimiste).
  • # DCVS vs CVS centralisés

    Posté par . Évalué à  6 .

    Je ne comprends vraiment pas le reproche du manque de communication faite aux DCVS.

    Si ce soir j'ai une super idée pour améliorer un projet X utilisant subversion :
    - je checkout les sources
    - je code
    - je génère un patch
    - j'envois mon patch à la liste de diffusion (je ne suis pas commiter du projet)

    Maintenant je veux faire la même chose avec le projet Y qui lui utilise un DCVS quelconque :
    - je clone le dépôt
    - je code (avec la possibilité de faire des commit locaux, des branches etc...)
    - je génère un patch que j'envoie sur le ML ou je fait un merge request en expliquant clairement mon code (je ne suis pas commiter donc pas de pull)

    Que ce soit l'un ou l'autre, si tu n'a pas les droits tu es obligé d'expliquer ce que tu fait et si tu as les droits rien ne t'empêche de ne rien dire à personne. Je ne vois vraiment pas ce qui change dans la manière de faire.

    Évidement l'exemple du dessus prend en compte que tu as un dépôt centrale qui fait office d'upstream. Je n'ai encore jamais vu de projet qui n'en n'avaient pas et je pense sincèrement qu'un projet qui ce constitue sur un réseau de dépôt non hiérarchisé ne tiendras pas plus de quelques développeurs sans voler en éclat.

    Note : tu as svk qui permet de faire du DCVS avec du subversion.

    Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

    • [^] # Re: DCVS vs CVS centralisés

      Posté par . Évalué à  2 .

      En fait, ce que tu dis, c'est que si on choisit un workflow comparable à Subversion, on n'a aucun problème, ce dont je suis absolument persuadé. Si je continue à utiliser ma comparaison avec le C, c'est comme si tu me disais qu'avec C, on peut bien coder, et je suis tout à fait d'accord. Il n'empêche qu'on peut mal coder en C et on peut utiliser git autrement que dans ce cas.
      • [^] # Re: DCVS vs CVS centralisés

        Posté par . Évalué à  1 .

        Tu as un exemple concret de projet qui n'a pas de dépôt de référence ?

        Si tu regarde le workflow du kernel c'est très différent de ce qu'on fait avec un CVS centralisé et pourtant magie, ils ont un dépôt de référence.

        On peut inverser ton raisonnement et dire que quelque soit l'outil si tu l'utilise mal tu as une probabilité importante de faire de la merde, je suis d'accord avec toi.

        Après c'est comme tout se fermer des fonctionnalités sous prétexte que ça peut être mal utilisé c'est vraiment dommage surtout que dans notre cas celui qui décide a probablement une influence importante dans le choix du workflow.

        Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

        • [^] # Re: DCVS vs CVS centralisés

          Posté par . Évalué à  0 .

          Alors, je vais commencer par te dire comme à Matthieu Moy : on se calme, pas la peine d'être aussi agressif. Je sais que vous êtes deux aficionados de git, mais là, je vous trouve tous les deux assez agressifs. Surtout que je dis que je vais essayer de m'y mettre à git, donc pas la peine de me parler de "fermer des fonctionnalités" blabla.

          Bref, pour répondre à ta première question, je vais t'en poser une autre : tu as des exemples concrets de programme en C avec des memory leaks ?
          • [^] # Re: DCVS vs CVS centralisés

            Posté par . Évalué à  6 .

            Désolé si tu m'a senti agressif je ne l'étais pas. Je ne suis pas particulièrement fan de git, vu que j'utilise aussi bien git, mercurial que subversion. Ce que j'esseyais de dire c'est que quelque soit l'outil quand il est mal utilisé il est mal utilisé c'est comme pour tout (même cat par exemple).

            subversion n'a jamais empêché qui que ce soit de faire un fork, mais de ce que j'ai crus comprendre ce qui te gène c'est la possibilité de pouvoir faire un pull d'un dépot différent de celui où on fait un push car ça faciliterais le maintient d'une version alternative du logiciel ?

            Je ne vois pas cela comme un mal ça peut simplifier le maintient de logiciel comme Iceweasel par exemple.

            D'une manière générale, je pense qu'il est mauvais de croire qu'un problème « social » peut être résolu par la technique. Ça me semble illusoire et ça peut toujours être contrecarré.

            Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

            • [^] # Re: DCVS vs CVS centralisés

              Posté par . Évalué à  3 .

              >> ce qui te gène c'est la possibilité de pouvoir faire un pull d'un dépot différent de celui où on fait un push car ça faciliterais le maintient d'une version alternative du logiciel ?

              En quelque sorte, oui.

              >> D'une manière générale, je pense qu'il est mauvais de croire qu'un problème « social » peut être résolu par la technique. Ça me semble illusoire et ça peut toujours être contrecarré.

              Et pourtant, avec notre OS préféré (que ce soit BSD ou Linux d'ailleurs), nous sommes entourés de mesures techniques qui règlent des problèmes sociaux. Ne serait-ce que l'existence de droits, et du compte root, "pour pas que les utilisateurs normaux fassent n'importe quoi", alors que c'est juste pour empêcher qu'ils puissent faire n'importe quoi, qu'ils en aient la possibilité. Et oui, ça peut être contourné et même des gens s'y emploient à longueur de journée. N'empêche que ça marche bien la plupart du temps.
          • [^] # Re: DCVS vs CVS centralisés

            Posté par (page perso) . Évalué à  5 .

            Attention, tu vas trouver mon commentaire super agressif, mais mais t'es quand même hallucinant, les gars argumentent, de façon certes un peu animée (j'imagine que c'est parce que pas grand monde ici comprend bien où tu veux en venir) mais à des années lumières de contributions elles vraiment agressives et toi tu te sens "agressé" ? /o\ Pfffff... on est pas des robots hein !

            Chippeur, arrête de chipper !

Suivre le flux des commentaires

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