Journal Pourquoi Git m'importe ?

Posté par (page perso) .
Tags : aucun
0
16
mar.
2008

Dans mon précédent journal,
j'ai clairement indiqué ma préférence sur les gestionnaires de versions
distribués (comme Git), par rapport aux
gestionnaires de versions centralisés (comme
Subversion). Je n'avais alors pas
justifié ma position, mais je souhaite maintenant le faire. C'est vrai ca,
pourquoi Git* m'importe ?



Un des arguments souvent rencontrés pour justifier l'intérêt de Git est la
vitesse des opérations. C'est vrai que c'est agréable de pouvoir commiter
instantanément. Pourtant, je travaille régulièrement avec svn, et ce manque de
rapidité n'est pas quelque chose qui me gêne beaucoup. Cet argument à lui seul
ne suffit pas à justifier le passage de svn à Git.



Les gestionnaires de versions distribués permettent, par définition, de
commiter depuis n'importe où (dans le train, le métro, l'avion, les toilettes,
etc.). Pourtant, ce genre d'utilisations reste assez marginal, et à l'exception
de quelques personnes, c'est une possibilité extrêmement peu utilisée.



On peut également reprocher certaines choses à svn (comme l'impossibilité
d'annuler un commit), mais ce sont des choix de design de subversion, et un
autre gestionnaire centralisé pourrait les corriger.



Pour ma part, je pense que le plus grand apport de git est son aspect
distribué, ce qui permet de mettre entre toutes les mains un gestionnaire de
versions avec ses avantages. Avec subversion, seules les personnes autorisées
peuvent accéder au dépôt et créer des branches pour faire des essais. De
l'autre coté, n'importe qui peut cloner un dépôt Git, créer sa branche
expérimentale et continuer à suivre les développements fait sur le dépôt
officiel.



Prenons un exemple (fictif) : je suis un utilisateur régulier du logiciel XYZ,
j'en suis content, mais je n'arrive jamais à m'y retrouver dans l'écran des
options. Je décide donc d'essayer de refaire cet écran, mais comme je passe
beaucoup de temps sur la tribune, il va probablement me falloir plusieurs
semaines avant de pouvoir proposer un patch à l'auteur.



Premier cas : le logiciel XYZ est versionné avec subversion. Je fais donc un
checkout du trunk, et je commence à travailler dessus. Au bout de deux
semaines, je commence à avoir une version intéressante de cet écran, mais entre
temps, le développement a continué sur le trunk, et une nouvelle option est
apparue. Je décide de faire un svn up, mais malheureusement, l'inévitable se
produit : un conflit sur plusieurs fichiers. Ce n'est pas très grave, j'arrive
à les corriger, et je peux me remettre au travail. J'arrive enfin à un écran
des options qui me convient, et juste au moment où j'allais me décider à
envoyer mon patch à l'auteur, je me dis que j'essayerais bien d'intervertir 2
options. Je fais ce dernier changement, mais pas le temps de le tester, je pars
en vacances. A mon retour, je me rends compte qu'intervertir ces 2 options
était une mauvaise idée. Malheureusement, comme je n'ai pas pu commité mes
changements, je me retrouve à devoir me rappeler ce que j'avais fait avant de
partir pour pouvoir annuler ces changements. Enfin, je peux proposer mon patch
à l'auteur. Ouf.



Deuxième cas : je fais un svn export du même dépôt, puis je créé un dépôt svn
local pour gérer mes avancées. Je peux tranquillement travailler sur mon écran
d'options. Quand j'arrive à quelque chose de convaincant, je propose un patch à
l'auteur, qui le refuse, car celui-ci ne s'applique pas sur le trunk. J'essaye
alors de me synchroniser avec le dépôt officiel, mais entre les nombreux
conflits et le trunk qui n'arrête pas d'évoluer, je finis par abandonner :(



Maintenant, le même scénario avec Git se serait beaucoup mieux passé. J'aurais
profité de tous les avantages d'un code versionné. Par exemple, j'aurais pu
commiter régulièrement mes avancées, ce qui m'aurais permis de profiter de git
diff, git log, etc. Si, après récupéré les mises à jour du dépôt officiel, je
me serais rendu compte que résoudre les conflits est plus compliqué que prévu,
je peux retourner à la révision précédente et continuer à travailler dessus (en
laissant le travail de résolution des conflits pour quand j'aurais plus de
temps/volonté à y consacrer). Enfin, je n'aurais rencontré aucune difficulté à
annuler un des mes changements. Bref, j'aurais pu profité des avantages d'un
code versionné.



Ici, on peut assez facilement s'en sortir avec svn et quelques bidouillages
(faire régulièrement des tarballs de ses avancées), mais imaginer que vous
vouliez vous mettre à plusieurs pour proposer une nouvelle fonctionnalité
majeure pour votre logiciel préféré. Bien entendu, vous n'avez pas accès au
dépôt officiel, sinon ce serait trop simple ;)



Pour moi, la grande force des gestionnaires de versions distribués est là :
pouvoir créer une branche même sans accès au dépôt officiel. Cette branche
distante est la seule façon sereine de faire des développements expérimentaux
tout en continuant à se synchroniser sur la base de code officielle. Les
gestionnaires de versions distribués cassent cette barrière entre ceux qui ont
accès au dépot officiel et les autres.





* je parle de Git, mais Mercurial ou Bazaar-NG ou un autre DSCM ferait aussi l'affaire.

  • # git > bzr

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

    Ave,

    Franchement, pour avoir découvert git avec le dév noyau et hal, c'est vraiment un bon logiciel. J'ajouterai quelques avantages :

    rapide : gérer les mégas de sources du noyau implique un code vraiment rapide, contrairement à bzr qui est lent, très lent
    stable : j'ai jamais réussit à mettre git dans la mouise alors que j'ai souvent de pb avec svn et bzr de malsuppression et autre erreur qui rende l'état du dépôt incohérent …
    maîtrise du commit : le "stage" avant commit est une merveille. Ça permet de maîtriser complètement ce qu'on met dans le commit.

    Y'en a certainement d'autres. Je suis déçu de baz, c'est pas lent et instable et ça ne pardonne pas pour du gestionnaire de source.

    Étienne.
    • [^] # Re: git > bzr

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

      ça m'intéresse beaucoup ce que tu dis car, effectivement, le gros défaut de SVN à mes yeux est la facilité avec laquelle tu peux tout foutre en l'air : un répertoire .svn malheureusement effacé dans un sous-répertoire, un fichier effacé ou déplacé sans utiliser SVN, un soft un peu buggué (NautilusSVN m'a plusieurs fois écrit une date de commit en 1970 qui plante complètement tout SVN).

      Est-ce que git est vraiment mieux à ce niveau ? Est-ce qu'il existe des interfaces permettant d'utiliser une interface git sur un serveur SVN ? Et le contraire ? Et y'a-t-il un document "Git pour les administrateurs SVN" qui me permettrait de convaincre mon admin SVN de tenter le coup de Git ? Et un document simple et clair à destinations des développeurs ?
      • [^] # Re: git > bzr

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

        Étant donné que, SVK mis à part, les gestionnaires de versions, décentralisés comme centralisés, ont tendance à stocker des fichiers opérationnels dans le répertoire de travail, tu ne peux guère éviter de lourdes conséquences à la suppression du répertoire .svn/, .cvs/, ou .bzr/. Quant au fichier déplacé ou supprimé sans utiliser SVN, on a toujours la possibilité d'en committé ultérieurement la modification.
        Et je ne pense pas que git soit plus à l'abri d'une interface graphique boguée.
        • [^] # Re: git > bzr

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

          Oui, git stocke aussi ces fichiers dans le répertoire courant (dans le répertoire .git). Il n'est donc pas plus à l'abri des erreurs de manipulations. La seule différence, c'est que git utilise un seul sous-répertoire, alors que svn créé un .svn par répertoire.
          • [^] # Re: git > bzr

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

            l'air de rien, ça peut déjà changer beaucoup je trouve. Je pense par exemple au bazar que j'ai obtenu quand un collègue a commité un répertoire automatiquement regénéré par eclipse à chaque compilation.
          • [^] # Re: git > bzr

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

            Par exemple, un grep récursif qui ne touche pas aux données de git, ça se fait avec

            grep toto -rn *

            (enfin, sauf si on veut que grep regarde aussi dans des fichiers cachés dans le répertoire racine)

            Avec subversion, le même va ignorer le .svn à la racine, mais pas les autres. Résultat, c'est beaucoup plus facile de foutre en l'air (là, j'ai pris grep, mais on peut faire pareil avec un « perl -pi -e ... » ...) une copie de travail svn qu'une copie de travail avec git. Par contre, les conséquences d'une corruption du .git/ sont en général plus désastreuses avec Git qu'avec SVN ...
            • [^] # Re: git > bzr

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

              Oui mai avec SVK, on n'a même plus besoin d'y penser puisque ces fichiers ne sont plus situés dans le répertoire de travail.
              • [^] # Re: git > bzr

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

                Oui, ce qui une pas bête idée du tout.

                Ceci dit, y'a pas de solution parfaite : avec SVK, si tu déplaces ta copie de travail, ça met aussi le bronx. Mais l'argument est que ça arrive moins souvent de déplacer sa copie de travail que de faire des conneries avec les .bidules/ à l'intérieur de la copie de travail.

                Au passage, avec Git, on peut simuler un comportement à la SVK en positionnant $GIT_DIR. Mais évidemment, si on a plusieurs repositories, c'est affreusement pas pratique de devoir changer la variable d'environnement à chaque fois qu'on change de copie de travail. C'est plus un truc pour cas particuliers dans des scripts que vraiment adapté à une utilisation quotidienne.
                • [^] # Re: git > bzr

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

                  J'ajouterais qu'il y a une toute récente option à SVK qui permet de déplacer le .svk dans le répertoire de travail mais pour l'instant, je n'ai pas bien compris l'intérêt.
                  Je voulais m'en servir pour pouvoir déplacer ma copie sur clé usb mais je ne vois pas comment replacer la dite copie dans le giron du SVK local...
      • [^] # Re: git > bzr

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

        git at bzr ont un seul répertoire à la racine du projet, c'est bien plus robuste que les .svn et les CVS éparpillés. C'est critique surtout lorsqu'on renomme ou qu'on supprime des dossiers.

        le bzr push est très lent, et supporte très mal une erreur lors de la transaction. J'ai pas encore testé pour git.

        Étienne.
  • # Re:

    Posté par . Évalué à  10 .

    > On peut également reprocher certaines choses à svn (comme l'impossibilité d'annuler un commit)

    On peut annuler un commit. Mais il faut savoir ce que tu entends par annuler. Ce qu'on peut faire avec svn, c'est ajouter une transaction qui annule la précédente. La précédente est toujours dans le dépôt mais n'est plus visible dans la version HEAD. Pour ce faire on "commit" l'inverse du commit qu'on veut annuler (ça demande qu'une ligne de commande).

    Notons qu'il n'y a guêre le choix.
    Tu soumets des modifications et avant que tu "annules" d'autres peuvent avoir fait un "svn update". Il y a le même problème avec git...

    Tu peux "réellement" annuler une transaction si t'es admin. C'est possible, mais ce n'est pas recommandé.

    > Avec subversion, seules les personnes autorisées peuvent accéder au dépôt et créer des branches pour faire des essais.

    Cette politique est à la discrétion de l'admin. Des admins autorisent tout le monde à écrire dans la branche /devel par exemple. D'autres mettent tout en rw pour tout le monde car on peut "annuler" toute modification.

    > De l'autre coté, n'importe qui peut cloner un dépôt Git, créer sa branche expérimentale et continuer à suivre les développements fait sur le dépôt officiel.

    Tu peux aussi le faire avec svn.

    > Maintenant, le même scénario avec Git se serait beaucoup mieux passé.

    Je ne vois pas pourquoi. Si des fichiers sont en conflit, ben ils sont en conflit. Avec svn ou git, ils sont en conflit.
    De plus tu n'es pas obligé de bosser sur la branche truck. Tu peux avoir une branche de développement que tu synchronises de temps à autres avec trunk (tu merges ce qui est fait dans trunk). C'est très commun comme usage de svn. Lorsque tu es content de ta version tu envois le diff entre ta blanche de développement et trunk. Ta branche de développement peut être un dépôt subversion local ou être sur le serveur principal.
    Mes dépôts subversions n'ont pas de développement direct dans /trunk. Tout est fait dans /devel. Lorsqu'une modification est satisfaisante, elle est fusionnée dans trunk. C'est un modèle qui a ses avantages et inconvénients. Il est présenté/discuté dans la doc de subversion (que tu devrais lire avant de parler de subversion).

    > Enfin, je n'aurais rencontré aucune difficulté à annuler un des mes changements.

    Il n'y a aucune difficulté à annuler des changements avec svn.

    > Ici, on peut assez facilement s'en sortir avec svn et quelques bidouillages

    On peut le faire sans bidouillage.

    > Pour moi, la grande force des gestionnaires de versions distribués est là : pouvoir créer une branche même sans accès au dépôt officiel.

    Pareil avec svn... Tu peux faire ton dépôt local si tu veux. Puis tu synchronises à la main (comme tu le fais avec git...).

    > Les gestionnaires de versions distribués cassent cette barrière entre ceux qui ont accès au dépot officiel et les autres.

    Non, l'intérêt n'est pas là.


    Franchement, si tu n'aimes pas svn et préfère git, ben utilises git. Mais ne dis pas que tel ou tel truc avec svn n'est pas possible sans te renseigner.
    • [^] # Re: Re:

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

      > Pareil avec svn... Tu peux faire ton dépôt local si tu veux. Puis tu synchronises à la main (comme tu le fais avec git...).

      Sauf que pour publier ton dépot, c'est plus compliqué. Ensuite, lors de la fusion des patchs, tu perds de l'information (la branche d'origine, les différentes étapes qui ont amené à ce patch, ...).

      >> Les gestionnaires de versions distribués cassent cette barrière entre ceux qui ont accès au dépot officiel et les autres.
      >
      > Non, l'intérêt n'est pas là.


      Un peu quand même. Si tu veux faire une modification importante à un logiciel, il est important de séparer le travail effectué en différents patchs, et le plus simple est de pouvoir commiter ces derniers. Les DSCM permettent de le faire facilement. Tu publies tes patchs (ta branche) qui pourra être ensuite fusionnée avec la branche principale (ou pas).
      • [^] # Re: Re:

        Posté par . Évalué à  0 .

        > Sauf que pour publier ton dépot, c'est plus compliqué.

        Ouuaiifff.

        > Ensuite, lors de la fusion des patchs, tu perds de l'information (la branche d'origine, les différentes étapes qui ont amené à ce patch, ...).

        Oui mais bof.

        > il est important de séparer le travail effectué en différents patchs, et le plus simple est de pouvoir commiter ces derniers. Les DSCM permettent de le faire facilement. Tu publies tes patchs (ta branche) qui pourra être ensuite fusionnée avec la branche principale (ou pas).

        Cet argument est pertinant. Ceux de Bruno Michel ne le sont pas.
        • [^] # Re: Re:

          Posté par . Évalué à  3 .

          > Cet argument est pertinant.

          Plus précisément, ce n'est pas l'aspect décentralisé qui est important. Mais l'aspect patch set. On ne travail pas avec un état des sources, mais avec un ensemble de patchs.
          Ça a des avantages (grosse souplesse, on peut plus facilement faire une branche qui est la fusion de plusieures parties d'autres branches) et des inconvénients (c'est plus le bordel).
          • [^] # svn + svk

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

            Plus précisément, si on veut faire des choses évoluées avec SVN, il est conseillé d'utiliser en plus SVK :
            http://search.cpan.org/dist/SVK/
            • [^] # Re: svn + svk

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

              Ca marche maintenant SVK ?

              Je pose la question, car la dernière fois que je l'ai utilisé, j'ai eu plus de problèmes qu'autre chose (avec des messages d'erreur qui ne voulaient pas dire grand chose). Ca doit faire 2 ans, donc svk a largement pu évoluer depuis, et j'aimerais savoir si tu as un retour d'expérience à nous faire partager sur le sujet.
              • [^] # Re: svn + svk

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

                Ça marche même très très bien.
                SVK ajoute à SVN la décentralisation sans remettre en cause le dépôt initial.
                Cependant, rien n'oblige à disposer d'un référentiel central : on peut travailler en local juste avec SVK : l'intérêt réside dans le fait que SVK ne stocke aucun de ses fichiers dans le répertoire de travail (et pour journaliser des fichiers de configuration ou des configurations de cfengine, c'est pas mal).
                Pour un retour d'expérience, je t'invite à lire l'article[1] de Nicolas Chuche publié dans le numéro 94 de Linux Magazine (pour git, il y a eu récemment deux articles dans les n°101 et 103).
                Par rapport à git ou bazaar, le seul cas que ces derniers pourraient éventuellement apporter quelque chose, c'est dans le cadre d'un poste de travail complètement isolé de l'Internet, et donc d'une quelconque liaison directe avec un éventuel référentiel (à moins de passer par une clé usb).
                Pour finir, si git n'était pas LE gestionnaire de sources de Linus, on n'en parlerait pas autant.


                [1]: http://articles.mongueurs.net/magazines/linuxmag94.html
                • [^] # Re: svn + svk

                  Posté par . Évalué à  2 .

                  > Pour finir, si git n'était pas LE gestionnaire de sources de Linus, on n'en parlerait pas autant.

                  ... mwouiii.

                  bon d'accord : on *pourrait* dire que la renomée de Linus aurait influencé sur la bonne prise en main de Git par tout un chacun mais je doute que ça soit suffisant... sinon pourportnawakilapluka..

                  bon je suis un convaincu : git me permet, facilement, tout ce que je souhaite ; la finesse en même temps que l' "exactitude" et la performance.. que demande le peuple..

                  bon après pour les arguments : bah voire les sources :p
                • [^] # Re: svn + svk

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

                  Ça marche même très très bien.
                  pour ma part j'ai au contraire une bien mauvaise expérience de svk...
                  J'ai voulu l'utiliser dans mon travail pour justement pouvoir bosser sur une branche "locale" pour ne commiter réellement que du code correct (mon code ne s'inscrivait pas dans le tron et pas envie de créer une branche sur le serveur pour ça, mais pas envie de ne pas commiter pour autant -> besoin de version décentralisée)
                  Les commits (et updates, mais surtout commit dans mon souvenir) sont très lents
                  Et j'ai eu de nombreux problèmes lors des synchros avec le trunk principal, des fichiers mal mergés, ...
                  Je crois que c'est la dernière fois que j'utilise svk, et je pense que je vais me tourner vers git-svn pour voir ce que ça donne

                  Je pense que git n'est pas populaire parce que c'est celui de Linus (qui d'ailleurs ne le maintient plus) Evidemment le fait qu'il l'ai initié a forcément joué mais il a aussi été très décrié à sa sortie.
                  Et on parle / parlais aussi avant de mercurial, bzr, monotone, ...
                  Mais ce dont je me rend compte c'est plutôt que beaucoup de personnes se sont mis à l'améliorer et est donc très vite venu au niveau des autres bon gestionnaires décentralisés, ceci justement parce qu'il est utilisé à la base pour le noyau. Mais on se rend compte qu'il est désormais utilisé pour des projets de taille beaucoup plus faible et je pense pas que ce soit uniquement pour les beau yeux de Linus...
                • [^] # Re: svn + svk

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

                  Pour finir, si git n'était pas LE gestionnaire de sources de Linus, on n'en parlerait pas autant.

                  OK, c'est peut-etre pour ca que beaucoup essayent git... Mais c'est pour ses qualites intrinseques qu'on y reste (et qu'on va jusqu'a l'utiliser sur des depots SVN).
            • [^] # Re: svn + svk

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

              J'approuve l'usage de SVK mais j'aurais plutôt utilisé « décentralisé » que le terme évolué ». Je ne trouve pas que le modèle décentralisé soit une évolution par rapport au modèle centralisé mais qu'ils sont complémentaires et ne répondent pas aux mêmes besoins. SVK en est la parfaite illustration.
    • [^] # Re: Re:

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

      On peut annuler un commit.

      Sauf à être admin, on ne peut pas annuler un commit avec svn. Par exemple, si je me suis trompé dans mon message de commit, je ne pourrais le changer, même si je m'en rends compte 2 secondes après avoir commité. Par contre, git permet de réellement annuler un commit (souvent pour le refaire plus proprement juste derrière).

      > Avec subversion, seules les personnes autorisées peuvent accéder au dépôt et créer des branches pour faire des essais.

      Cette politique est à la discrétion de l'admin. Des admins autorisent tout le monde à écrire dans la branche /devel par exemple. D'autres mettent tout en rw pour tout le monde car on peut "annuler" toute modification.


      C'est bien ce que je dis : seuls les gens autorisés peuvent le faire. Éventuellement, l'admin peut autoriser tout le monde mais, en pratique, très peu de projets libres ont un svn ou tout le monde peut commiter.

      > De l'autre coté, n'importe qui peut cloner un dépôt Git, créer sa branche expérimentale et continuer à suivre les développements fait sur le dépôt officiel.
      Tu peux aussi le faire avec svn.


      Si je n'ai qu'un accès en lecture seule sur le dépôt, je ne vois pas comment faire ca.

      Il est présenté/discuté dans la doc de subversion (que tu devrais lire avant de parler de subversion).

      J'ai lu la doc de subversion, je pense savoir de quoi je parle, et je n'ai vu nulle part comment faire une branche distante et la garder à jour. Maintenant, si tu as un lien qui dis le contraire, postes-le.

      > Pour moi, la grande force des gestionnaires de versions distribués est là : pouvoir créer une branche même sans accès au dépôt officiel.

      Pareil avec svn... Tu peux faire ton dépôt local si tu veux. Puis tu synchronises à la main (comme tu le fais avec git...).


      Justement, avec Git, ce n'est pas à la main, et c'est ce qui fait toute la différence : git pull est là pour ca.

      Franchement, si tu n'aimes pas svn et préfère git, ben utilises git. Mais ne dis pas que tel ou tel truc avec svn n'est pas possible sans te renseigner.

      J'utilise quotidiennement svn au boulot, et ce depuis plusieurs années. En plus, je le trouve tout à fait adapté à cette utilisation. Par contre, pour les logiciels libres (notamment tous ceux hébergés sur sourceforge, gna, savannah, etc.), j'espère que Git va devenir plus populaire, car il permet vraiment de nouvelles manières de développer.
      • [^] # Re: Re:

        Posté par . Évalué à  2 .

        > Sauf à être admin, on ne peut pas annuler un commit avec svn. Par exemple, si je me suis trompé dans mon message de commit, je ne pourrais le changer, même si je m'en rends compte 2 secondes après avoir commité. Par contre, git permet de réellement annuler un commit (souvent pour le refaire plus proprement juste derrière).

        Oui. Mais c'est du détail. Et ça relève aussi de la "politique". Est-il normal de supprimer un commit d'un gestionnaire de version public ? Pas évident de répondre à ça. Pour ma part je pense que non. C'est comme supprimer un commentaire ou un journal sur dlfp. Que l'admin puisse le faire est normal. Que l'utilisateur puisse le faire est plus discutable et d'autant plus pour un gestionnaire un version.

        > C'est bien ce que je dis : seuls les gens autorisés peuvent le faire.

        Et pour ton dépôt git ?
        Tout le monde peut écrire dedans ?
        Et es-ce parce que tu vas avoir ton propre dépôt que ça va être mergé en upstream ?
        J'en doute.
        La majorité des admins te donne un espace sur leur serveur svn si tu en as besoin.
        Il faut aussi prendre en compte les effets sur la communication. Si toutes les branches sont sur le même serveur, et bien tout le monde peut voir le travail des autres, et merger, et le proposer en upstream, etc.
        Si chaqu'un fait ça dans son coin...

        > Si je n'ai qu'un accès en lecture seule sur le dépôt, je ne vois pas comment faire ca.

        Ça se fait aussi avec svn. Après si tu ne veux pas le faire, ben ne le fait pas.
        Es-ce que c'est plus pratique de le faire git ? Probablement.

        > J'ai lu la doc de subversion, je pense savoir de quoi je parle, et je n'ai vu nulle part comment faire une branche distante et la garder à jour.

        C'est vrai que ça ne saute pas yeux. Mais l'idée est là :
        http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr(...)

        Si en plus ce avec quoi tu dois te synchroniser est un dépôt svn, c'est encore plus simple.
        J'image que tu vas dire que c'est un enfer, etc mais ça se fait très bien si tu n'as pas deux mains gauches et un cerveau de poulpe.

        > J'utilise quotidiennement svn au boulot, et ce depuis plusieurs années.

        Désolé, mais parfois on ne dirait pas.

        > j'espère que Git va devenir plus populaire, car il permet vraiment de nouvelles manières de développer.

        Pour développer dans son coin c'est très bien.
        Mais in fine, pour la majorité des projets, es-ce bien pour le projet ? J'en suis moins sûr.

        C'est clair que git ou des choses comme ça ont leur place pour les projets hors-norme. Par exemple Linux. Le dernier patch de 2.6.23 à 2.6.24 :
        10209 files changed, 776107 insertions(+), 483031 deletions(-)

        Tu travailles souvent sur des projets de ce type ?
        Moi pas.
        En jours ouvré ça fait 1000 lignes d'ajouté par jour !
        • [^] # Re: Re:

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

          T'as déjà utilisé Git IsNotGood ??
          • [^] # Re: Re:

            Posté par . Évalué à  2 .

            Mouais. Mais par "obligation" et durant très peu de temps (l'upstream utilisait git). Je ne prétend pas être un utilisateur et encore moins un spécialiste.
          • [^] # Re: Re:

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

            Non, de toute évidence.

            Il ne sait pas de quoi il parle, mais il adore venir troller sur les journaux qui en parlent.
          • [^] # Re: Re:

            Posté par . Évalué à  8 .

            T'as déjà lu les messages de IsNotGood, Marc ? :)
            Si jamais t'écris un jour un logiciel et que tu veux avoir un retour d'un non-utilisateur, demande à IsNotGood, c'est le seul à assurer ce service en permanence et cela pour tout logiciel. Basé sur la technologie ZOB (Zoning-On-Blogosphere), ce à quoi il s'adonne vraisemblablement toute la journée, il pourra te faire un compte rendu intégral des contresens et idées reçues qui pullulent autour de ton logiciel. En plus c'est gratuit, profites-en.
        • [^] # Re: Re:

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

          > http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr(...)

          Merci pour le lien. Je ne connaissais pas. Je pense que j'avais sauté cette section en me disant que vendor, c'est juste pour suivre ce qui vient de l'extérieur (svn ou autre), mais sans le modifier.

          > C'est clair que git ou des choses comme ça ont leur place pour les projets hors-norme.

          Justement, je pense que git a aussi sa place pour les projets moins importants. Il favorise les développements en parallèle en simplifiant le suivi et la réunification de branches.
          • [^] # Re: Re:

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

            Voici deux exemples de projets de petite taille pour lesquels git est particulièrement bénéfique.


            Le premier exemple est les bundles pour TextMate :

            « Whilst Git was created by Linus for managing the Linux project, I get the feeling that Git’s raison d’être was to manage TextMate bundles. Weird since Linus probably doesn’t use TextMate.

            A TextMate bundle is a combination of common/default snippets and personal snippets. Those personal snippets may even be useful for other people. Other people way want them. They may even join the set of default snippets. »

            Source : http://drnicwilliams.com/2008/02/03/using-git-within-a-team/

            En effet, les bundles de TextMate (ou les extensions d'emacs ou les fichiers de syntaxe de vim, etc.) sont des fichiers que l'on partage, mais qui sont souvent légèrement modifiés : changer le raccourci clavier pour telle fonctionnalité car il est dur à taper sur un clavier azerty, remplacer une couleur par une autre, désactiver telle option parce que l'on a un plugin qui fait ca en mieux...



            Le deuxième exemple est les plugins pour Ruby on Rails.

            « Also, I believe that a lot of developers will also be motivated to move their plugins/gems to GitHub because they simply can't always maintain their own libs and/or just hope people will fork their project and contribute back. »

            Source : http://railsontherun.com/2008/3/5/starting-the-migration-to-(...)

            « This marks a turning point for me in my opensource contribution. The barrier to entry for pushing patches is so low that I expect to see myself cloning a bunch more repos and making my teeny tiny fixes. »

            Source : http://blog.bitfluent.com/post/26592090

            Quand on utilise régulièrement les plugins pour Ruby on Rails, on
            se retrouve souvent à devoir faire des modifications sur les plugins : traduire les messages d'erreur, remplacer une bibliothèque par une autre (rmagick -> mini-magick), adapter le plugin pour qu'il passe avec la dernière version de rails... La plupart de ces modifications n'arriveront jamais sur le dépôt officiel, et l'on se retrouve à refaire les mêmes changements à chaque mise à jour d'un plugin, car c'est plus rapide de refaire les changements que d'essayer de merger les changements avec svn. De l'autre coté, avec git et github, on est encouragé à faire des branches séparées et les partager.
          • [^] # Re: Re:

            Posté par . Évalué à  2 .

            > Justement, je pense que git a aussi sa place pour les projets moins importants. Il favorise les développements en parallèle en simplifiant le suivi et la réunification de branches.

            Tout dépend où on met la barre. Il y aura forcément du flou. Puis si les utilisateurs sont habitués à git, ben autant utiliser git même s'il n'est pas "nécessaires".
      • [^] # Re: Re:

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


        Par exemple, si je me suis trompé dans mon message de commit, je ne pourrais le changer, même si je m'en rends compte 2 secondes après avoir commité.


        C'est juste faux, il suffit d'avoir le hook qui va bien.

        Après c'est un choix de l'admin du serveur... Mais après tout c'est comme tout ce qui est collaboratif, ce sont les admins qui décident... Je trouve ça plus sain qu'un truc ouvert où on peut faire ce qu'on veut et où l'admin doit fermer des possibilités.
        • [^] # Re: Re:

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

          Je ne suis pas sûr que l'on se soit bien compris.

          Mon exemple est le suivant : on m'envoie un patch par mail, je l'applique en local, le teste, et ca semble bien marcher. Je le commite donc dans le dépôt officiel. Dans mon message de commit, je remercie l'auteur du patch. Juste après, je retourne dans client mail, et là, je me rends que j'ai mal orthographié le prénom de l'auteur du patch.

          Sous git, je peux annuler ce commit, et le refaire avec le prénom correctement orthographié. Sous svn, quel hook me permettrait de faire ca ?
          • [^] # Re: Re:

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

            http://subversion.tigris.org/faq.html#change-log-msg

            On s'est donc bien compris, il suffit effectivement d'un hook pour autoriser de telles modifications.

            Ensuite pour l'annulation d'un commit, un simple svn merge -r revAAnnuler-1:revAAnnuler suffit. Ca ne supprime pas la révision annulée du référentiel, cela en crée une nouvelle qui annule la précédente, ce qui me semble être correct pour un gestionnaire de version (on ne perd rien...)
          • [^] # Re: Re:

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

            Pourquoi ne pas _simplement_ corriger la faute de frappe dans un nouveau commit ?
            • [^] # Re: Re:

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

              Parce qu'il s'agit du *message de commit*, pas d'un fichier.

              D'ailleurs, avec GIT il aurait meme pas eu a refaire son commit, parce qu'il n'aurait pas pu faire de faute d'orthographe: il aurait fait un pull depuis le repository du contributeur et le commit aurait apparu directement comme etait fait par le contributeur en question :)
    • [^] # Re: Re:

      Posté par . Évalué à  4 .

      Évidemment qu'on peut faire des choses "exotiques" avec svn, moyennant une grande maîtrise de l'outil et de moultes configurations, mais sérieusement on ne peut pas prétendre que subversion soit ultimement adapté (et conçu pour !) les use cases que l'autre du journal présente.

      Si le but est de ne pas perdre de temps ni se faire des noeuds dans le cerveau pour arriver à ses fins, alors je conçois sans problème que pour faire du développement décentralisé un gestionnaire de version décentralisé soit plus adapté qu'un gestionnaire de version centralisé :)
  • # Utilisez git-svn

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

    Si vous voulez contribuer à un projet qui utilise SVN mais que vous préférez git, utilisez git-svn. Ca importe le repository SVN dans git en local.

    Ca permet de faire des commits locaux, des branches de tests, des synchronisations avec d'autres développeurs (les avantages d'un vrai repository git), tout en laissant le choix aux autres de continuer à utiliser SVN.

    On peut faire apparaître les branches SVN dans git. On peut aussi se récupérer les dernières versions SVN (git-svn fetch), commiter sur le SVN si on en a les droits (git-svn dcommit).

    Exemple:

    $ git-branch -a
      master
    * feature1
      developer1/master
      developer1/feature1
      developer1/feature2
      git-svn
      mypublicrepos/master
      mypublicrepos/feature1


    Pour initier le repository git local, on peut soit prendre toutes les révisions SVN (ce qui prend du temps à télécharger!), soit juste prendre la dernière révision, et travailler à partir de là.

    Bref, on peut avoir tous les avantages de git même si le projet utilise SVN.
    • [^] # Re: Utilisez git-svn

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

      git-svn est très bien mais on est loin d'avoir tous les avantages de git

      On est limité à un modèle bien défini pour soumettre ses modifications. git-svn dcommit ne permet par exemple que de "rebaser" ses derniers commits.

      J'utilise git-svn tous les jours et j'en suis vraiment très content. Il y a eu de très gros progrès récemment. Mais je préfère de loin une utilisation tout git.
      • [^] # Re: Utilisez git-svn

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

        En fait, je n'ai pas vraiment compris dans quels scénario il est préférable d'utiliser rebase au lieu de merge et vice versa.

        (Cette question n'a rien à voir avec git-svn)
    • [^] # Re: Utilisez git-svn

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

      Sauf que git-svn, ça prends 3 plombes à faire une copie compléte du dépot. Alors bien sur, tu as des options pour faire des copies partiels, mais perso, j'ai parfois à voir dans les logs por savoir pourquoi tel chose a été faite.
      • [^] # Re: Utilisez git-svn

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

        Mais l'équivalent avec git de "svn annotate" est très lent parait-il, donc de toute façon pour savoir qui a fait quoi avec git...
  • # Vidéo

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

    Peut-être que des gens ne connaissent pas donc je poste la vidéo de Linus qui fait une présentation de Git aux gens qui bossent chez Google :

    http://video.google.fr/videoplay?docid=-2199332044603874737&(...)

    Comme souvent avec Linus c'est drôle et en plus on comprend mieux es avantages de Git.
    • [^] # Re: Vidéo

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

      je ne peux que plussoyer c'est un vrai plaisir d'ecouter cette video ! Il est vraiment fort ce linus
    • [^] # Re: Vidéo

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

      Excellente vidéo en effet.

      Et j'adore un des commentaires de cette vidéo : He's the Dr. House of Software Architects :)

      L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

    • [^] # Re: Vidéo

      Posté par . Évalué à  1 .

      Puta** de flash de mer**!

      Est-ce qu'une bonne âme peut récupérer le .flv et le mettre sur un service comme dl.free.fr

      merciiiiiiiiiiiiiiiiiii!
    • [^] # Re: Vidéo

      Posté par . Évalué à  3 .

      La vidéo est vraiment sympa et la référence à House est bien vue.
      Je me suis mis à GIT depuis que je me suis mis dans la tête de bosser sur la nouvelle pile graphique pour linux.
      J'avoue que je retouve fidèlement tous les avantages dont il parle. D'ailleurs maintenant, j'ai du mal à supporter les contraintes d'un système centralisé (CVS/SVN me donnent des boutons).
      Bref... j'invité vraiment les projets open source à passer sous GIT. En plus c'est du C sous GPL donc du vraiment bon.
  • # les perfs

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

    Ca dépend de la taille du repository. Si le repository est gros, SVN est vraiment tres lent et avec GIT on sent la difference.

    Flock par exemple est sur SVN, et c'est gros parce qu'on a tout le code source de Firefox dedans (avec les metadonnees CVS en plus). Pour ma part (et avec d'autres collegues) j'utilise GIT, et:
    1) c'est bien plus rapide.
    2) ca ne met pas ma machine a genoux quand je fait un update
    3) ca prends moins de place sur le disque - alors que j'ai tout l'historique en local!
    • [^] # Re: les perfs

      Posté par . Évalué à  -6 .

      > 2) ca ne met pas ma machine a genoux quand je fait un update

      Il reste des Z80 ?
  • # Comparatif ?

    Posté par . Évalué à  1 .

    Afin de pouvoir choisir intelligement, il faut pouvoir comparer. Ainsi, je me demande quels sont les avantages/inconvénients de mercurial, git et bazaar, en termes de performances, de facilité de mise en place, de fonctionnalités, de facilité d'administration...

    Quelqu'un aurait-il des pistes sur ce sujet ?
  • # mettre un tag

    Posté par . Évalué à  1 .

    Avec svn, il manque une fonctionnalité de tag au sens CVS : mettre un tag manuellement sur un groupe de fichiers hors de la logique de version SVN.

    Est-ce possible avec git ?

    Exemple :

    fichier1 : r100 (numero de version SVN)
    fichier2 : r99
    fichier3 : r103
    fichier4 : r100
    fichier5 : r101

    Avec CVS on peut tagguer fichiers 1, 2, 3, (uniquement ces 3) avec TAG_V1 par exemple. et faire plus tard des update, checkout et diff par rapport à cette version TAG_V1.
    Mais avec SVN ce n'est pas possible.

    C'est très utile quand 2 développeurs travaillent en parallèle, et que certaines modifs de l'un doivent être livrées, alors que d'autres modifs de l'autre developpeur ne seront pas livrées tout de suite.
    • [^] # Re: mettre un tag

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

      Faire exactement ce que tu demandes, non, ce n'est pas possible, puisque git ne suit pas l'approche par fichiers.

      Dans un cas comme celui-ci, tu vas simplement créer une nouvelle branche (appelons-la V1) et y merger ce qui t'intéresse. Et comme de toute façon, chacun des deux développeurs travaille dans sa branche, ce sera très facile à faire.
    • [^] # Re: mettre un tag

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

      Mmm... Je dirais mauvais principe de réflexion, changer le principe de réflexion plutôt que le logiciel.
      Le gros problème de CVS est justement cette gestion par fichier : un tag peut alors être très incohérent, car le tag n'est pas précis dans le temps pour l'ensemble du logiciel.
      Je suis passé il y a peu de CVS à SVN, ça m'a gonflé pas mal au début cette gestion des tags par la création obligatoire d'une branche pour le soft en entier, et puis... Après réflexion, c'est génial : c'est bien le soft en entier qu'on versionne, pas un fichier!

      Dans ton exemple, TAG_V1 ne correspondrait pas un une V1 vraiment pendant que ton collègue n'a pas encore fait son patch. Ca serait inconsistant, une personne faisant un checkout sur ton soft en entier avec un filtre sur le Tag TAG_V1(qu'il verrait dans son gestionnaire, donc il se dira "super, la V1 est tagguée!) penserait avoir une V1, mais... Il lui manquera des fichiers, et ça ne compilera pas. Pas bon du tout.
  • # toilettes

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

    >Les gestionnaires de versions distribués permettent, par définition, de commiter
    > depuis n'importe où (dans le train, le métro, l'avion, les toilettes, etc.).


    Comment !? Tu n'as pas enore internet dans ta toilette ?
    Ah bhe oui, alors dans ce cas, Git c'est mieux :-)
  • # la Comtesse, à l'aide !

    Posté par . Évalué à  4 .

    mais où se cache la contrepèterie dans le titre du journal ? plize!
  • # Multiple repositories

    Posté par . Évalué à  1 .

    Je rajouterai deux killer features (avec l'accent je vous prie) de git:

    - Pouvoir facilement recuperer du code de differents repository du meme projet (je fais ca tout le temps):
    git-clone git://anongit.fdo.org/git/mesa
    cd mesa
    git-remote add toto git://toto.org/git/mesa

    Et hop on peut recuperer les branches de toto faire du cherry picking et compagnies. A si vous connaissez titi ben vous pourrez aussi faire la meme chose.

    - Git bitsect très utile pour retrouver une régression.

    Donc git c'est bien ;)
    • [^] # Re: Multiple repositories

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

      Un détail : la syntaxe « git-clone » est dépréciée en faveur de « git clone » (avec un espace, pas un tiret).
      • [^] # Re: Multiple repositories

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

        Pourquoi? Je croyais que toutes les commandes "git foo" pouvaient aussi être utilisées avec "git-foo" et vice versa.

        Je préfère avec le tiret, ça fait des pages de man moins longues pour chaque commande.
        • [^] # Re: Multiple repositories

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

          http://www.kernel.org/pub/software/scm/git/docs/RelNotes-1.5(...)

          Deprecation notices
          -------------------

          * From v1.6.0, git will by default install dashed form of commands
          (e.g. "git-commit") outside of users' normal $PATH, and will install
          only selected commands ("git" itself, and "gitk") in $PATH. This
          implies:

          - Using dashed forms of git commands (e.g. "git-commit") from the
          command line has been informally deprecated since early 2006, but
          now it officially is, and will be removed in the future. Use
          dash-less forms (e.g. "git commit") instead.

          - Using dashed forms from your scripts, without first prepending the
          return value from "git --exec-path" to the scripts' PATH, has been
          informally deprecated since early 2006, but now it officially is.

          - Use of dashed forms with "PATH=$(git --exec-path):$PATH; export
          PATH" early in your script is not deprecated with this change.

          Users are strongly encouraged to adjust their habits and scripts now
          to prepare for this change.


          Les raisons pour ça, entre autres :

          * Les git-bidule ne permettent pas les aliases. Par exemple, chez moi, « git st » fait « git status », mais pour que « git-st » le fasse aussi, Git ne peut pas.

          * Les git-bidule ne permettent pas les options globales, genre « git --no-pager foo ».
  • # Comment faire du développement dans l'industrie avec SGVD ?

    Posté par . Évalué à  1 .

    Il me parait évident que les outils de gestion de versions distribués sont bien plus intéressants que les outils centralisés. En plus la notion de changeset est tellement plus pertinente que le suivit des changements par fichiers que cette façon de travailler s'est imposé au outils de gestion de versions propriétaires (ClearCase UCM).

    Ce qui me semble difficile à implémenter c'est un cycle de développement avec des branches/streams de développement, d'intégration, de test, de release et de maintenance.

    En plus dans un environnement où à la fois Unix et Windows peut-être utilisé il n'est pas facile de choisir un outil qui convienne aux 2.

    Avez vous des idées sur comment utilisé ces outils pour répondre à ces 2 contraintes ?

Suivre le flux des commentaires

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