Journal Git ou Mercurial ?

Posté par (page perso) .
Tags : aucun
0
14
fév.
2008


Cher journal,


voici mes réflexions sur les DSCM (Distributed Source Code Management), enfin
surtout Git et Mercurial, et tant qu'à faire,
j'aimerais bien avoir ton avis sur la question.


Je vais attaquer un projet pour lequel je vais utiliser un DSCM (non, je n'ai
vraiment pas envie d'utiliser Subversion), et je me suis donc
penché sur le sujet. D'un point de vue technique, les 2 gagnants sont Git et
Mercurial. Du moins, c'est l'impression que j'en ai, et elle est partagée avec
d'autres personnes avec qui j'en ai discuté. Je ne nie pas que les autres
(darcs, bazaar-ng, etc.) aient des qualités, mais ils m'intéressent moins que
Git et Mercurial.

Coté Mercurial, je vois comme avantage le fait que je l'ai déjà utilisé (ce qui
n'est pas le cas de Git) et que son utilisation est réputée plus simple. Ca ne
fait pas très lourd, surtout qu'on m'a dit que Git a fait de gros progrès sur
ce point avec les dernières versions.


De l'autre coté, j'ai l'impression que Git est en train de marquer des points
dans la guerre des DSCM, et de venir de plus en plus populaire. Depuis les
annonces de Mozilla et OpenSolaris,
je ne crois pas avoir croisé beaucoup de projets qui utilisent Mercurial, alors
que je vois régulièrement des dépôts Git (utilisé pour du code, mais aussi pour
du packaging et de la doc). Du coté des hébergeurs, même topo : Tuxfamily a récemment annoncé le
support des dépôts Git, et je connais des hébergeurs spécialisés dans Git comme
GitHub, mais pour Mercurial, je ne pense pas
en avoir croisé.


Dans la communauté Ruby on Rails, cela me
semble encore plus frappant. La manière plus ou moins officielle de distribuer
des plugins est d'offrir un accès anonyme à un dépôt svn (en lecture seule,
l'accès). Mais plusieurs développeurs de plugins connus utilisent Git pour
développer les plugins, et synchronisent le svn juste pour les releases. Il
existe également des projets visant à utiliser les plugins quand on utilise Git
(comme Giston
ou Git-rails). Il me semble
que capistrano possède également un module pour Git. Et pour Mercurial ? je
n'ai rien vu, mais alors rien de rien.


Bref, j'ai l'impression que Git est en train d'écraser la concurrence, ce qui
veut dire que le développement de Git va surement avancer plus vite que celui
de Mercurial, qu'on trouvera de plus en plus d'outils pour Git, et surtout, que
des potentiels contributeurs auront plus de chances de connaitre Git que
Mercurial. Je pense que je vais choisir Git surtout pour ce dernier point, car
j'espère attirer des contributeurs dans les prochains mois et je ne voudrais
que le DSCM soit le moins possible un point de bloquage.


Et vous, chers lecteurs, vous-en pensez quoi ?

  • # Re:

    Posté par . Évalué à  6 .

    > Et vous, chers lecteurs, vous-en pensez quoi ?

    Que tu devrais demander en premier à ceux qui vont participer à ton projet. Si tu es tout seul, un "DSCM" est sans intérêt.
    • [^] # Re: Re:

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

      Oui, je vais voir avec les autres personnes qui vont participer au projet. Mais j'aimerais bien attirer des contributeurs plus ponctuels dans les prochains mois, et pour eux, c'est plus dur de demander vu que je ne les connais pas. Je considère que les personnes qui vont lire ce journal sont suffisamment représentatives des potentiels contributeurs que cela vaut le coup de demander ici.
      • [^] # Re: Re:

        Posté par . Évalué à  1 .

        Pense aussi aux contributeurs non-codeurs, du genre traducteurs, graphistes, documentalistes. Ils ne sont pas forcément au fait de l'utilisation de tous les DSCM, dans ce cas il vaut mieux que la syntaxe reste simple.
      • [^] # Re: Re:

        Posté par . Évalué à  5 .

        > Je considère que les personnes qui vont lire ce journal sont suffisamment représentatives des potentiels contributeurs que cela vaut le coup de demander ici.

        Pour ma part, je préfère un bon Subversion. C'est simple, puissant, la doc est excellente, c'est intégré à Eclipse que j'utilise, ça marche partout, ça le fait.
        Je connais mal git et mercurial. J'ai bien regardé le principe et c'est très intéressant. Mais très intéressant pour quelques projets hors-norme.

        J'ai l'impression que tu veux un DSCM car c'est "hype", par curiosité. Et pourquoi pas. La curiosité, l'exitation d'utiliser un truc "hype" sont excellents pour la motivation et in fine pour le projet.
        Mais si c'est la raison, et je la respecte lorsqu'elle est "avouée", tu n'as que faire de l'avis des autres. Fonce, prend ce qui te fait le plus kiffer. Si ton projet est bon, d'autres viendront. Que ça soit svn ou cvs ou git est accessoire (au moins au début). Lorsque le projet aura plus de contributeurs, tu pourras toujours changer de gestionnaire de version si le besoin s'en fait sentir.

        > non, je n'ai vraiment pas envie d'utiliser Subversion

        Et pourquoi ?
        • [^] # Re: Re:

          Posté par . Évalué à  1 .

          Typiquement le truc que je n'aime pas dans svn, cvs, clearcase, c'est la gestion par fichier qui n'a aucun sens. Un patch s'applique souvent sur plusieurs fichiers, et une modification partiel par fichier n'a pas de sens d'un point de vue du développement du soft. Le code peut ne pas compiler.

          La gestion par patch set correspond plus à ce qu'est le code source.

          Pour combler ce manque, il exite les tags, mais il faut encore penser à les poser et souvent la granularité est trop grosse.

          "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

          • [^] # Re: Re:

            Posté par . Évalué à  6 .

            Il ne faut pas confondre la gestion par fichier et la notion de changeset..

            Avec Clearcase tu n'as pas la notion de de transaction atomique et si tu commites un ensemble de fichier tu n'as aucune garantie que tu pourras commiter l'ensemble des fichiers en 1 seul bloc.

            Avec SVN la notion de changeset existe et si un fichier entre en conflit au moment du commit la transaction est annulée jusqu'à ce que tu résolves les conflits.

            La différence entre SVN la plupart des DVCS ets que lui historise des révisions de fichiers alors que les autres historise des diffs.
            Dans la pratique, ceci n'a aucune conséquence, ca revient à faire la différence entre les piquets et les barrières.

            Pour les tags avec SVN tu às tjs un numéro de révision qui correspond à un état de ton arborescence.
            toutefois une bonne GCL ne peut se passer de marquer des configuration importantes et le "svn cp" sert aussi à initier des branches simplement
            • [^] # Re: Re:

              Posté par . Évalué à  3 .

              Précision et correction:
              Pour svn il faut parler de révision d'aborescence et non de fichier.
              Si on commite un changeset on obtient une nouvelle révison de toute l'arborescence
              Chacune des révision porte porte un identifiant unique et peut donc être retrouvée.
              Ce qui n'exclut pas de tagger certaines révision, explicitement puisqu'on dispose de "cheap copy" .


              Cheap Copies

              Subversion's repository has a special design. When you copy a directory, you don't need to worry about the repository growing huge—Subversion doesn't actually duplicate any data. Instead, it creates a new directory entry that points to an existing tree. If you're a Unix user, this is the same concept as a hard-link. From there, the copy is said to be “lazy”. That is, if you commit a change to one file within the copied directory, then only that file changes—the rest of the files continue to exist as links to the original files in the original directory.

              This is why you'll often hear Subversion users talk about “cheap copies”. It doesn't matter how large the directory is—it takes a very tiny, constant amount of time to make a copy of it. In fact, this feature is the basis of how commits work in Subversion: each revision is a “cheap copy” of the previous revision, with a few items lazily changed within. (To read more about this, visit Subversion's website and read about the “bubble up” method in Subversion's design documents.)

              Of course, these internal mechanics of copying and sharing data are hidden from the user, who simply sees copies of trees. The main point here is that copies are cheap, both in time and space. Make branches as often as you want.

              http://svnbook.red-bean.com/en/1.2/svn.branchmerge.using.htm(...)
              • [^] # Re: Re:

                Posté par . Évalué à  3 .

                mwai enfin SVN ya la théorie et la pratique.

                En théorie les développeurs de SVN affirment que les temps des opérations sont à peu près proportionnels à la quantité de données transférée et que la taille totale du repo influe peu.

                En pratique sur les gros projets au bout de quelques mois, quand le repository devient énorme, les temps de commit, update et j'en passe explosent (à plusieurs dizaines de secondes sur des transferts de quelques ko au max) et le bousin devient inutilisable.

                Alors copy cheap ? pas cheap ? Ce qui me semble clair c'est que ya des algos d'une complexité trop importante qui ont du échapper à la vigilance de leur auteurs, en tout cas.
                • [^] # Re: Re:

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

                  Alors copy cheap ? pas cheap ? Ce qui me semble clair c'est que ya des algos d'une complexité trop importante qui ont du échapper à la vigilance de leur auteurs, en tout cas.

                  Ça ne peut pas être pire que la résolution des conflits dans darcs, en tout cas ;-)

                  Je médis mais c'est ce que j'utilise au quotidien et j'en suis très content (pour mon usage sur des projets de taille moyenne).
                • [^] # Re: Re:

                  Posté par . Évalué à  1 .

                  Et bien sûr , tu as des témoignages et d'autres preuves irréfutables pour appuyer tes allégations et prouver qu'il ne s'agit pas de pur FUD
                  • [^] # Re: Re:

                    Posté par . Évalué à  2 .

                    Bien sûr que j'ai des témoignages :) Tous mes collègues seraient sans doutes prêts à témoigner tellement ça commence à saouler tout le monde.

                    Je n'ai aucune raison de sortir des bobards. Je préfère que tout le monde soit informé des limites des softs qu'ils pourraient être ammenés à utiliser histoire de faire le bon choix, plutôt que de cacher une limitation que j'ai constaté (pour faire quoi ? éviter de heurter ceux qui pense que le libre c'est tellement beau que les softs libres sont systématiquement purs et parfaits ?)

                    Et en même temps, je serais le premier à me réjouir si un jour cette limitation disparaît.

                    Ceci étant, sur un petit projet (ou un projet que vous pouvez découper dans pleins de repository) faites du SVN si vous n'avez pas d'autres raisons de vous en priver (process de dev, que sais-je), car avec peu de volume à mon avis le ralentissement mettra de nombreuses années avant de se faire ressentir.

                    Simplement sur un projet avec un gros volume de données, oubliez SVN en l'état actuel de ce soft.
          • [^] # Re: Re:

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

            Ca tombe bien, coté svn la gestion est pas changeset, pas par fichier (contrairement à cvs).
        • [^] # Re: Re:

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

          >>> Je connais mal git et mercurial. J'ai bien regardé le principe et c'est très intéressant. Mais très intéressant pour quelques projets hors-norme

          Tu a regardé la vidéo de la conf de linus sur Git ? => http://www.youtube.com/watch?v=4XpnKHJAok8

          Il est très véhément dans sa défense des DSCM, et ce pour tous les projets (pas seulement pour "quelques projets hors-norme".
          • [^] # Re: Re:

            Posté par . Évalué à  2 .

            Et lorsque Linus a parlé, la vérité est établie.

            Les DVCS sont sans doute plus puissants que les VCS centralisés ,nul n'en doute. Maiss de leur puissance découle aussi une certaine complexité.
            Ainsi on n'est obligé d'appréhender les concept de branches (pull/push)
            de privilégier les merges qui est parfois une discipline hasardeuse tous les formats de fichiers ne s'y prêtent pas forcément. Avec un DVC le schéma de concurrence pessimiste est impossible/complexe puisque chacun travaille sur sa branche(/lock/modify/unlock)

            Va demander à un AMO, ou un fonctionnel de merger des fichiers Word.
            Va demander à de nombreux développeurs en forfait 1 mois de maitriser les outils de merge, les concepts des DVCS avant d'être opérationnels avec tout ce qu'il ont d'autres à assimiler dans leur nouveau contexte alors qu'on leur demande juste de sauvegarder leur travail dans un espace securisé.

            Les DVCS sont donc des outils de niche qui selon moi se limitent à des projets libres purement communautaires ou interviennent des développeurs chevronnés et/ou passionnés.
            Ce type d'outil n'est pas adapté au monde de l'entreprise.
            Or de plus en plus les entreprises participent aussi à l'essor du libre
            (contribution occasionnelles, passage de produit en open source, modèle en double licence, ...)
            Dans ce cas les DVCS aussi puissants soient-ils (travail deconnecté , pas d'identifcation) sont un frein.

            Reste un argument:
            les DVCS qui supportent vraiment les 2 modes d'accès centralisé et distribué, mais à quoi bon alors faire compliqué lorsqu'on peut faire simple. Au cas où on en aurait besoin ?
            Ceux qui ont travaillé avec ClearCase multisite (mode distribué de Clearcase) me comprendront. Le multisite en tant que palliatif des piètres performances entre 2 sites distants (proxy) n'a plus lieu d'être avec SVN qui est très performant même à distance.
            Alors pourquoi se compliquer la vie avec 1 branche par site quand on travaille sur les même sources alors qu'on peut tous travailler dans la même.


            Et ne parlons pas de l'aspect "user centric" lié à l'usage d'un DVCS vs "repository centric". Le premier impose un modèle d'organisation.
            Les dictateurs en entreprises sont rarement éclairés et bienveillants .

            Ceci explique sans doute cela:
            http://blogs.open.collab.net/svn/2008/02/subversion-stil.htm(...)
            • [^] # Re: Re:

              Posté par . Évalué à  2 .

              > Va demander à de nombreux développeurs en forfait 1 mois de maitriser les outils de merge, les concepts des DVCS avant d'être opérationnels avec tout ce qu'il ont d'autres à assimiler dans leur nouveau contexte alors qu'on leur demande juste de sauvegarder leur travail dans un espace securisé.

              La question est surtout :
              Pour quel gain ?
              Pour la majorité des projets, ça n'apporte rien. D'un côté c'est pénalisant et souvent ça n'apporte rien.
              Pour ma part, et je suis développeur, je n'ai jamais senti le besoin d'un DVCS. Ceci dit, je n'en nie pas les atouts, je n'en conteste pas le principe. Le développement de Linux (le noyau) est une "forêt d'arbre avec plein de branches". Tous les projets n'ont pas cette complexité. Fort heureusement.

              C'est un peu comme connaitre l'assembleur. Pour certain projet c'est super. Mais que ça soit super (voire indispensable) pour certains projets, n'implique pas que c'est important pour tous les projets. Imposer l'assembleur ou un DVCS comme ticket d'entré à un projet sans une bonne justification est contre productif.


              En passant, un hommage à Subversion.
              Subversion est un excellent gestionnaire de version. Pas révolutionnaire, c'est clair. Mais excellent. Incontestablement l'un des meilleurs. Je suis navré de voir comme il est si souvent "boudé" alors que les développeurs de subversion ont fait un excellent travail, avec une remarquable compréhension du besoin, le tout avec un souci de la qualité (fiabilité, compatibilité, documentation, internationnalisation, etc) que j'aimerai voir dans beaucoup de projet.
              Chapeau bas.

              La superbe doc de Subversion :
              http://svnbook.red-bean.com/en/1.4/svn-book.pdf
              Pour ceux qui ne connaissent pas les gestionnaires de version, c'est aussi une excellente lecture.
              • [^] # Re: Re:

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

                Tous les outils que tu utilise sont géniaux, les autres sont forcément moins bon vu que tu les utilise pas. Je suis sur qu'on peut te decerner sans problème la palme du meilleur trolleur de LinuxFr 2007 et 2008 (j'anticipe mais tu es bien parti).

                Tu as prouvé ta méconnaissance de git dans ce thread, n'en rajoute pas. svn est correct. git est juste mieux, plus rapide pour les opérations courantes, possibilité de tout faire hors-ligne et de push plus tard, et à des trucs supers avancés comme bissect.
                • [^] # Re: Re:

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

                  Pour le coup (et c'est suffisamment rare pour le noter), je suis d'accord avec IsNotGood. Subversion est bon, surtout parce qu'il est simple à utiliser quand tu débutes, et que les concepts de base sont assimilables rapidement.

                  Ensuite, c'est juste un débat sur distribué/centralisé, plus que sur les outils eux même (git ou subversion). Dans certains cas, le distribué n'apporte rien, par exemple :
                  - un petit projet qui débute dans son coin, avec peu de codeurs
                  - un projet internet à une entreprise qui a besoin d'avoir un référentiel centralisé
                  - un projet où les développeurs sont sédentaires et ne passent pas leur temps à coder pas dans un avion

                  L'aspect distribué apporte des avantages nombreux, mais aussi une certaine complexité, d'après ce qu'on en dit. La question sur un projet est donc de savoir si l'aspect distribué fait partie des besoins, ou n'a que peu de chances d'être utilisé.
                  • [^] # Re: Re:

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

                    simple a utiliser ....

                    Enfin la dernière fois que j'ai essayé de faire un merge avec subversion, ça m'a pris plus d'une heure. A la fin j'ai décidé d'utiliser bazaar-ng avec le plugin svn pour faire mon merge, c'était beaucoup plus simple.
                    • [^] # Re: Re:

                      Posté par . Évalué à  0 .

                      > Enfin la dernière fois que j'ai essayé de faire un merge avec subversion, ça m'a pris plus d'une heure.

                      C'est beau de le reconnaitre.
                • [^] # Re: Re:

                  Posté par . Évalué à  4 .

                  > git est juste mieux

                  Mieux pour quoi ?
                  Pour les trucs de ouf comme Linux où il y a 200 branches en parallèle et aucune synchronisé ? Ou tout le monde s'échange des patchs pour faire des testes ? Ou 50 branches différente veulent tester le patch bidule ?
                  Oui dans ce cas, git est mieux. Indiscutable mieux.

                  Désolé d'être modeste, mais je ne bosse pas sur ce type de projet. Je n'ai pas le niveau.
                  Et désolé d'être cruel, mais il n'y a qu'une toute petite minorité de développeur qui peuvent s'aventurer dans Linux (je parle du coeur, je ne parle pas d'écrire seulement un driver (ce qui est très respectable)).
                  Et fait, je ne suis pas modeste, j'ai la prétention d'être un bon développeur. Pas une pointeur pour bosser sur le noyau Linux, mais un bon développeur. Un mec qu'on ne berne pas si je peux me permettre.

                  Il y en a qui jongle avec les diff et merge à longueur de journée. Je les admire.
                  Tu fais parti de cette catégorie ?
                  Bravo pour toi.
                  Mais tout le monde n'est pas dans cette catégorie.
                  Il ne faut pas laisser croire qu'un bon programmeur, qui fait son taff correctement, qui est une bonne contribution, un développeur sur qui tu peux faire confiance et pas un développeur qui te vomie un patch en disant que pour les bugs il regardera ça plus tard, a besoin d'être dans cette catégorie.
                  Que s'il se satisfait de subversion alors ce n'est qu'un minable. C'est faux.

                  Et les autres ne devrait pas croire d'utiliser git est une preuve d'intelligence ou la marque d'un bon développeur. Git n'est qu'un outil parmis d'autre. Ça doit s'apprendre 3 ou 4 jours.
                  • [^] # Re: Re:

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

                    J'ai juste dit que globalement, les opérations de bases sont plus rapides sous git (et on rajoute tout ce qu'on peut faire sans avoir accès au serveur de synchro). Comme c'est un outil, et que ca ne prend que 3-4 jours à l'apprendre (et encore, les commandes de bases, bah elles se ressemble toute), git add, git rm, git diff, git commit....

                    Les projets sur lesquels j'utilise git sont des petits projets. Le gros projet sur lequel je bosse utilise hélàs un outil largement depassé (CVS) et j'espère qu'on switchera vite.

                    git permet je pense d'aller plus vite (pour le développement, je ne parle des autres cas cités précédemment) au cout d'une certaine discipline humaine.

                    Quand à savoir qui a la plus grosse, je te la laisse :D
                    • [^] # Re: Re:

                      Posté par . Évalué à  2 .

                      Et sous windows aussi il est plus rapide.
                      Il est spécifiquement conçu pour être optimal avec Linux

                      Hg est moins rapide mais plus portable

                      Bref le choix de git dépend du contexte du projet et ce n'est certainement pas un outil universel.
        • [^] # Re: Re:

          Posté par . Évalué à  1 .

          Subversion ne permet pas de gérer plusieurs changesets en local.

          C'est particulièrement énervant quand on veut faire une modification importante, mais pas suffisante pour créer une branche.
          • [^] # Re: Re:

            Posté par . Évalué à  2 .

            > Subversion ne permet pas de gérer plusieurs changesets en local.

            Bof...
            Les copies sous Subversion ne sont pas cher. Donc l'admin te fait une branche sur le server et l'affaire est pliée. Les bons admin laissent tous les utilisateurs faire des copies dans, par exemple, branches/devel. Aucun risque de perdre des données, c'est versionné :-)
            Une fois le boulot terminer, il suffit d'un "svn rm ma_branche". Et rien est perdu évidemment. Ce n'est simplement plus visible dans la version HEAD.

            Et comme ça tu profites des sauvegardes du serveur, les autres peuvent piocher dans ton boulot ou y participer en un rien de temps, etc...
            Plein d'avantages à ne pas négliger.

            Mais si t'aime bosser en solo...

            > C'est particulièrement énervant quand on veut faire une modification importante, mais pas suffisante pour créer une branche.

            Les branches sous subversion ne coûte rien.
            • [^] # Re: Re:

              Posté par . Évalué à  2 .

              C'est beaucoup plus lourd à gérer/fusionner le "une branche par développeur" que le simple enregistrement d'une série de changesets avec un DSCM.
              • [^] # Re: Re:

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

                SVN 1.5 permet(tra) de gérer plusieurs changesets en local, par le biais de changelists : http://blogs.open.collab.net/svn/2007/07/one-quality-of-.htm(...)
                • [^] # Re: Re:

                  Posté par . Évalué à  2 .

                  Cette fonctionnalité est appréciable et permettra d'atténuer les critiques faite à SVN en ce qui concerne les commit locaux, mais il ne s'agit pas d'une véritable branche locale.

                  La conséquence est que les changesets doivent être disjoints. Si 2 changements ou correction de bug concernent le même fichier on ne pourra pas distinguer à quel changement s'applique les différentes modifs sur ce même fichier et il faudra impérativement commiter les 2 changelist qui se recouvrent.
        • [^] # Re: Re:

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

          Je préfère un DSCM à svn pour plusieurs raisons : pouvoir commiter même sans accès au net (dans le train), parce que c'est plus simple à administrer, parce que je vais surement avoir à gérer plusieurs branches et que les DSCm me semblent bien plus efficaces que svn pour cela.

          Quant aux avantages de svn, j'ai du mal à les voir.

          La simplicité ? je ne pense pas que svn soit plus simple que git ou mercurial.
          Puissant ? heu, tu pourrais détailler ce que svn a de plus puissant qu'un DSCM ?
          Doc excellente ? Oui.
          Intégration à eclipse ? Oui, mais Git a aussi un plugin, et je n'utilise pas eclipse.
          Ca marche partout ? Non, ca ne marche que quand on est connecté au dépôt (donc pas dans le train).
          Ca le fait ? Oui, mais un DSCM, ca le fait aussi ;-)
          • [^] # Re: Re:

            Posté par . Évalué à  -1 .

            > La simplicité ? je ne pense pas que svn soit plus simple que git ou mercurial

            Pourquoi pas.

            > Puissant ? heu, tu pourrais détailler ce que svn a de plus puissant qu'un DSCM ?

            J'en sais rien. Mais svn reste puissant. copie gratuite, une révision est un snapshot, accès concurrent au serveur sans problème, les conflits sont gérés, les attributs (type mime, information sur eof (native, crlf, etc), bit exécutable), les liens symboliques, synchronisation de dépôt, backup à chaud, etc.

            > Ca marche partout ? Non, ca ne marche que quand on est connecté au dépôt (donc pas dans le train).

            Ouais, ouais, ouais....
            Si on sait faire un patch et qu'on n'est pas un manchot ça je gère ce type de situation (qui reste exceptionnelle).
            Effectivement, si tu bousses tous les jours dans le train, il vaut mieux un DVCS.
    • [^] # Re: Re:

      Posté par . Évalué à  7 .

      Selon moi, un "DSCM" a un intérêt même si l'auteur est tout seul, au contraire d'un "SCM".
      • [^] # Re: Re:

        Posté par . Évalué à  1 .

        Faut pas pousser. Dans ce cas tu as ton propre dépôt subversion par exemple, et je ne vois pas ce qu'un DSCM pourrait t'apporter (par définition j'ai avis d'ajouter).
        • [^] # Re: Re:

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

          Ben c'est le piège du nom ça. :-)

          Un DSCM tel que Git t'apporte :

          - facilité à faire des branches
          - bissection
          - puissante visualisation d'historique
          - facilité à travailler sur plusieurs machines
          - performance
          • [^] # Re: Re:

            Posté par . Évalué à  2 .

            > - facilité à faire des branches

            Avec subversion il suffit d'un "svn cp" (tu as toujours la traçabilité de l'historique).

            > - bissection

            ???
            C'est un merge ?
            Facile avec subversion.

            > - puissante visualisation d'historique

            Pareil.

            > - facilité à travailler sur plusieurs machines

            ???
            Je ne vois pas en quoi.

            > - performance

            Si t'es tout seul à l'utiliser... (c'est l'hypothèse de Hank Lords).
            • [^] # Re: Re:

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


              > - bissection

              ???
              C'est un merge ?
              Facile avec subversion.

              La bissection n'a rien à voir avec le merge et il n'y a, à ma connaissance, pas d'équivalent, simple, sous Subversion.

              En gros tu dis "rev 1234 je suis sûr que ça marchait, rev1300 ça marche plus" et ça va te permettre de parcourir simplement les différents états de ton code entre les deux révisions jusqu'à ce que ça fonctionne...
              • [^] # Re: Re:

                Posté par . Évalué à  2 .

                > à ma connaissance, pas d'équivalent, simple, sous Subversion.

                "svn switch" ?
                Ce n'est pas compliqué, il suffit d'ajouter "-r [révision]" et voila.
                • [^] # Re: Re:

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

                  Je vois mal le rapport entre svn switch est git-bissect (ou hg bissect).

                  Avec bissect, tu definis deux tags good et bad (l'un tu es sur que ca marchait, l'autre tu es sur que ca marche). Il prend un changeset au milieu, revient à cette état, tu test ton bug et tu marque cet etat good ou bad. Et ensuite, on recoupe, jusqu'a trouvé le commit qui introduit le bug.

                  C'est faisable avec un SCM classique, à la main, mais c'est très chiant.
                  • [^] # Re: Re:

                    Posté par . Évalué à  4 .

                    Je ne vois ce qu'il y a de miraculeux là-dedans et en quoi un VCS centralisé ne le permettrait pas.

                    Bref encore une commande occasionnelle qui n'a pas été implémentée dans SVN et on en fait tout un foin.
                    On finira bien par la retrouver dans un plugin si elle est si importante.
                    Inutile de polluer l'outil avec une commande de plus.

                    Quand on regarde le man de git on prend déjà peur.
                  • [^] # Re: Re:

                    Posté par . Évalué à  0 .

                    C'est que ça...
                    Un bloque note...

                    > C'est faisable avec un SCM classique, à la main, mais c'est très chiant.

                    $ svn switch -r 100 [url]
                    $ # tu testes, ça marche.
                    $ svn -r 101 [url]
                    $ # tu testes, ça ne marche pas. Tu notes sur un postit que la version (ou changeset si tu préfères) 101 a introduit une régression
                    $ svn update # tu passes à la version HEAD
                    $ # Tu récupères (ou visualise seulement) le diff qui a introduit le bug (tu peux le faire n'importe quand).
                    $ svn diff -c 101 > patch_qui_sucks # le '101' que tu as écrit sur le postit
                    $ # tu peux évidement regarder le log du "changeset" 101
                    $ svn log -r 101
                    # blabla

                    Et voila.

                    Après tu peux faire des trucs plus exotique comme :

                    $ svn switch [url]/branche_stable
                    $ svn merge -c 101 [url]/trunk
                    $ # ça marche sur la version stable. Donc le "changeset" 101 n'est pas le seul en cause dans le problème.
                    $ # un autre bug a probablement aussi été intégré à la de développement dans autre version que la version 101.
                    $
                    $ # tu peux forcer la version d'un sous-répertoire
                    $ svn update -r 90 lib
                    $ # le répertoire lib est à la version 90 et le reste à la version 95 par exemple
                    $ svn merge -c 101
                    $ # Damned, ça marche ! Le problème est une combinaison d'un bug dans /lib et du "changeset" 101


                    C'est si compliqué que ça ?
                    Bien des choses sont possibles avec svn si on le connait. Et fort heureusement il n'est pas compliqué tout en étant puissant.

                    Si git est plus simple, j'aimerai bien un démontration comme je viens de le faire avec svn.
                    • [^] # Re: Re:

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

                      Déjà ce qui fait peur, c'est qu'il faille passer une url. On peut pas le faire sur place, en étant deconnecté ?

                      Pour la documentation, je te laisse le soin de faire un man git-bisect, tout est très clairement documenté (ici par exemple http://linux.die.net/man/1/git-bisect)

                      git contrairement à svn est documenté par des pages man ...

                      L'avantage de svn ici c'est que les changesets sont consécutifs, donc la bissection est plus aisée.

                      Bien des choses sont possibles avec git si on le connait. Et fort heuresement, il n'est pas compliqué tout en étant puissant. La moitié des commandes sont en shell ou en perl. On a rarement l'occassion de voir des outils plus Unix, et plus faciles à customiser.
                      • [^] # Re: Re:

                        Posté par . Évalué à  1 .


                        Déjà ce qui fait peur, c'est qu'il faille passer une url. On peut pas le faire sur place, en étant deconnecté ?

                        Ben par définition avec un outil centralisé tu stockes pas tout un repository en local donc oui faut aller récupérer sur le serveur ce qu'il te faut et juste ce qu'il te faut au moment ou tu en as besoin.

                        Avec ton système si tu n'as cloné que récemment le projet, tu vas déjà "explicitement" recupérer la branche de ta révision ou ta révision (qui va remonter la branche associée)dans ton archive.
                        Avec svn le switch ne transfère que le strict nécessaire
                        Bref rien de choquant.

                        Le seul avantage que je vois à un DVCS est l'effet proxy.
                        A force tu conserves en local toute les révisions que tu as récupérées. peut-être avec l'avantage du cache en moins. Il ne se vide pas automatiquement lorsqu'il devient trop volumineux.
                        Espérons que les DVCS sont concus pour mutualiser le stockage des archives en local parce qu'avec 50 clones de tout un projet ca va vite saturer la place.
                        En outre il n'est pas inconcevable (si ce n'est pas déjà le cas) de disposer de cache avec SVN si le besoin s'en fait ressentir. Perforce le fait bien et il est centralisé


                        git contrairement à svn est documenté par des pages man ...

                        Ben oui encore une preuve que cet outil est concu d'abord et avant tout pour des linuxiens pur et dur et pas prévu être multiplatforme.


                        Bien des choses sont possibles avec git si on le connait. Et fort heuresement, il n'est pas compliqué tout en étant puissant. La moitié des commandes sont en shell ou en perl.

                        Même remarque
                        Un projet multiplateforme qui a vraiment besoin de l'aspect distribué a donc tout intérêt a utiliser Hg.
                        Le posteur du journal nous a confié qu'il bossait sur RoR donc ca devrait l'aider à prendre sa décision puisque ruby et RoR tout comme python répondent au critères de portabilité et peuvent donc concerner des devs d'horizons différents.
                      • [^] # Re: Re:

                        Posté par . Évalué à  1 .

                        > Déjà ce qui fait peur, c'est qu'il faille passer une url.

                        $ svn info | grep ^URL
                        Et tu l'as l'url.

                        > On peut pas le faire sur place, en étant deconnecté ?

                        Vas pas sur dlfp, on ne peut pas poster des commentaires en batch.

                        zul exige un dlfp décentralisé !

                        > http://linux.die.net/man/1/git-bisect

                        Le "git bisect run my_script" est effectivement cool.

                        > git contrairement à svn est documenté par des pages man ...

                        la command svn est très bien documentée.
                        Exemple :
                        $ svn help update
                        update (up): Actualise la copie de travail par rapport au dépôt.
                        usage : update [CHEMIN...]

                          La copie de travail est actualisée à la révision HEAD ou à la révision
                          précisée par l'option -r.
                          L'opération effectuée sur chaque objet est donnée par un caractère :
                            A  ajouté
                            D  supprimé
                            U  modifié
                            C  en conflit
                            G  fusionné

                          La première colonne concerne l'objet, la seconde ses propriétés.
                          Un 'B' en troisième colonne indique qu'un verrou a été volé ou cassé.

                        Options valides:
                          -r [--revision] ARG      : ARG (peut aussi être une étendue ARG1:ARG2)
                                             L'argument d'une révision peut être :
                                               NUMÉRO       numéro de la révision
                                               '{' DATE '}' révision disponible à cette date
                                               'HEAD(       dernière révision du dépôt
                                               'BASE'       rév. de base de la copie de travail
                                               'COMMITTED'  dernière propagation à ou avant BASE
                                               'PREV'       révision juste avant COMMITTED
                          -N [--non-recursive]     : opère sur un seul répertoire
                          -q [--quiet]             : essaie de se taire
                          --diff3-cmd ARG          : utilise ARG comme commande de fusion
                          --username ARG           : précise le nom d'utilisateur ARG
                          --password ARG           : précise le mot de passe ARG
                          --no-auth-cache          : ne conserve pas les éléments d'authentification
                          --non-interactive        : pas de demande interactive
                          --config-dir ARG         : fichiers de configuration dans ce répertoire
                          --ignore-externals       : ignore les références externes


                        Ça vaut un man.
                        • [^] # Re: Re:

                          Posté par . Évalué à  3 .

                          non, ça ne vaut pas un man, un man ça a une structure, c'est pas un truc en vrac, un man ça peut se lire dans un pager (donc avec toutes les features d'un pager, comme la recherche) ou en dehors d'un term (konqueror)
                          • [^] # Re: Re:

                            Posté par . Évalué à  0 .

                            Si tu veux, c'est une question de goût.

                            > c'est pas un truc en vrac

                            Ben justement, ce n'est pas un truc en vrac. Si on ne connait pas un outil, utiliser les pages man est rarement la voix la plus facile. Si on connait et que les pages man concentrent toute la doc, ce n'est pas pratique.

                            Si tu veux l'équivalent des pages man :
                            http://svnbook.red-bean.com/en/1.4/svn.ref.html

                            Et notes bien ça :
                            http://svnbook.red-bean.com/en/1.4/svn.ref.svn.html#svn.ref.(...)
                            Une option a toujours la même signification quelque soit la sous-commande. Ce n'est pas du "en vrac".
                            Ça rend les commandes et leurs options trivials à assimiler et donc l'aide en ligne ("svn help") est largement suffisante. Évidemment il faut avoir compris le fonctionnement global de subversion (c'est comme ça pour tous les programmes).

                            > un man ça peut se lire dans un pager

                            Git c'est 139 pages man, plus de 20 000 lignes. À 50 lignes par page, ça fait "seulement" 400 pages. Je te souhait bien du plaisir pour assimiler git avec ça.
                    • [^] # Re: Re:

                      Posté par . Évalué à  2 .

                      Meuh non
                      On va te refaire un script shell au ptit poil qui traite ton cas et on vas le rajouter dans le "man".
                      On lui trouveras un joli petit nom qui en jette après "bisection" on l'appellera "quadrisec....

                      Et après on pourra troller comme des oufs en disant que svn sait pas le faire autrement qu'à la mano. Dans les choux SVN
                  • [^] # Re: Re:

                    Posté par . Évalué à  2 .

                    Prenons 1 autre cas d'utilisation qui me parait plus courant:

                    Dans de nombreux projets, on n'héberge pas que des fichiers sources mais aussi des fichiers qui ne peuvent pas être mergé car on ne dispose pas d'outils appropriés(charte graphique , images, fichiers UML, XML, ...). Embêtant pour celui qui devra tout refaire ses modifs à la mano pour ne pas écraser celle du premier qui a commité.

                    Avec SVN tu places le fichier en lecture seule et tu obliges à locker le fichier avant toute modification.

                    Avec un DVCS pas facile de locker ledit fichier dans toutes les branches de la création surtout lorsqu'on a pas accès aux repository des autres.
                    Seule solution déporter la gestion de la concurrence (bug tracker, serveur web) à un outil tiers pour "centraliser" en comptant sur la rigueur et l'infaillibilité des membres du projet.
                    Mais on y arrive, tout comme à résoudre ton cas.
            • [^] # Re: Re:

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

              > Avec subversion il suffit d'un "svn cp" (tu as toujours la traçabilité de l'historique).

              Et pour le merge, tu fais comment avec SVN ?

              > > - puissante visualisation d'historique
              >
              > Pareil.

              Non, t'as jamais vu gitk ou n'importe quel équivalent pour dire ça. Premier truc : avec SVN, tu ne vois que l'historique des branches, jamais l'historique des merge. Il manque un truc capital pour comprendre l'historique. SVN voit un arbre, Git voit un DAG.

              Après, essayes de voir l'historique de deux fichiers ensembles avec SVN.

              > > - performance
              >
              > Si t'es tout seul à l'utiliser... (c'est l'hypothèse de Hank Lords).

              Lapin compris. Git est incroyablement plus rapide que SVN, que tu l'utilise tout seul ou pas, c'est un fait.

              Bon, je te propose un truc : si tu veux faire un comparatif Git Vs SVN, utilise un peu les deux. Là, tu parles de manière affirmative d'un truc que tu connais à peine, c'est dommage.
              • [^] # Re: Re:

                Posté par . Évalué à  2 .


                Et pour le merge, tu fais comment avec SVN ?


                Non, t'as jamais vu gitk ou n'importe quel équivalent pour dire ça. Premier truc : avec SVN, tu ne vois que l'historique des branches, jamais l'historique des merge. Il manque un truc capital pour comprendre l'historique. SVN voit un arbre, Git voit un DAG.


                Après, essayes de voir l'historique de deux fichiers ensembles avec SVN.


                La mémoire des merge vient avec la nouvelle version de SVN (encore en bêta mais parfaitement utilisable.)
                http://blogs.open.collab.net/svn/2007/05/the_subversion__1.h(...)
                Cette fonctionnalité attendue le hisse la hauteur des meilleurs DVCS sur ce point et il n'est guère étonnant que les DVCS étaient plus avancés sur ce point car on ne peut pas travailler sans les branches avec eux, même sur de petits projets

                Gageons qu'avec cette avancée des plugins du type de celui que tu cite ne tarderons pas à venir.

                Mais si tu penses que tout est pour le mieux dans le monde merveilleux des merges pour les DVCS, je t'invite à te rendre sur ce wiki très intéressant qui relate tous les approches pour merger au mieux dans les DVCS et visiblement la "silver bullet" n'existe pas.
                http://revctrl.org/CategoryMergeAlgorithm
                Le mieux est donc encore de s'isoler le moins possible en intégrant au plus tôt les modifs pour ne pas tomber dans des cas tordus. Ce à quoi n'incite pas les DVCS

                Ah et autre chose Clearcase dispose de la mémoire de merge depuis longtemps et dans sa version UCM te permet de consulter l'historique des merge au niveau de l'arborescence (projet en entier) et du fichier.
                Bref ce n'est pas une spécificité des DVCS



                Lapin compris. Git est incroyablement plus rapide que SVN, que tu l'utilise tout seul ou pas, c'est un fait.

                Et sous windows aussi ?
                Un truc qui a été nativement conçu pour ne cibler qu'une seule plateforme, j'ai du mal à le croire


                Vraiment, les seuls avantages d'un DVCS sont les suivants:
                - Pas besoin d'administration (ouvrir un accès) ni d'en passer par un diff /patch pour un contributeur occasionnel (un pull de sa branche et c'est parti). Ca limite le scope au monde du libre. Le monde de l'entreprise a de toute façon besoin de contrôler les accès.

                - Possibilité d'historiser plusieurs versions en local. Avec SVN on peut de toute façon travailler en déconnecté et à peu de frais, on peut monter un petit repository en local et scripter des commits successifs dans une sous-branche sur le serveur. En général il n'est pas bon de travailler isolé trop longtemps de toute façon car les merges sont plus délicats.
                Et si vraiment ca te manque tant que ça tu as svk
                http://svk.elixus.org/view/HomePage


                En regard de la complexité dans la gestion des branches ca me parait mince comme avantages
              • [^] # Re: Re:

                Posté par . Évalué à  1 .

                > Et pour le merge, tu fais comment avec SVN ?

                Avec la commande "svn merge".
                Surpris ?

                > jamais l'historique des merge.

                Juste.

                > Lapin compris. Git est incroyablement plus rapide que SVN, que tu l'utilise tout seul ou pas, c'est un fait.

                Super. Si tu fais 2000 commit dans la journée c'est définitivement un plus. Si tu n'en fait que 10 en moyenne (ce qui est une belle valeur lorsque tes commit sont fait intelligement), ben t'as gagné au mieux 1 minute.
                Mais c'est super sinon.
        • [^] # Re: Re:

          Posté par . Évalué à  3 .

          Sans entrer beaucoup dans les détails, rien que le fait de ne pas avoir besoin de continuellement être connecté au réseau, est déjà un intérêt.
          Tu peux être dans ton dépôt local, faire des commits, des clones et tout ça sans besoin d'accès à ton dépôt central (si tu en as un).

          Bon, il y a plein d'avantages à utiliser un DSCM et je ne les connais pas tous, ni ne les évalue bien tous (je débute) mais tu peux trouver plus d'infos sur le site de Mercurial par ex ou le livre indiqué sur ce site.

          Vous l'aurez compris, pour ma part j'ai choisi Mercurial, et j'en suis assez content. Pour Git je ne connais pas.

          mes 2 cts.
          • [^] # Re: Re:

            Posté par . Évalué à  1 .

            > rien que le fait de ne pas avoir besoin de continuellement être connecté au réseau, est déjà un intérêt.

            Ben tu n'en a pas besoin pour svn.
            Tu auras besoin d'être connecté lorsque tu as besoin du dépôt (commit, log, etc).
            Tu en a pas besoins pour diff, revert, status, etc.
            • [^] # Re: Re:

              Posté par . Évalué à  1 .

              Sauf que tu as souvent besoin du dépôt parce que certaines combinaisons de renommages/suppressions/déplacements ne peuvent être faites sans commits intermédiaires...
              • [^] # Re: Re:

                Posté par . Évalué à  2 .

                Sauf que tu as souvent besoin du dépôt parce que certaines combinaisons de renommages/suppressions/déplacements ne peuvent être faites sans commits intermédiaires...

                Combinaisons que tu fais bien sûr souvent. Tu n'as pas besoin d'accéder au repository pour :
                - rajouter un élément
                - supprimer un élément
                - déplacer un élément

                D'autant que des suppressions et déplacements d'éléments, ce n'est pas fréquent, alors des combinaisons qui nécessiteraient d'accéder au repository, je ne pense pas qu'on puisse qualifier leur fréquence de souvent
                • [^] # Re: Re:

                  Posté par . Évalué à  5 .

                  Dans ce thread la plupart des subversion fanboys répondent aux manques de ce logiciel par "ça ne sert pas souvent", "tu n'as en pas besoin"...

                  Dans ma boite on utilise Subversion au quotidien, mais on rencontre ces problèmes régulièrement. Donc oui c'est suffisamment souvent pour être ennuyeux!

                  La seule raison qui ne nous fait pas migrer, c'est l'interface TortoiseSVN, sinon on serait déjà sous Mercurial ou GIT.
                  • [^] # Re: Re:

                    Posté par . Évalué à  2 .

                    Dites nous de quoi vous avez besoin, on vous expliquera comment vous en passer…
                  • [^] # Re: Re:

                    Posté par . Évalué à  4 .

                    Vi vi vi c'est marrant on a parlé de la bisection et montré que c'était
                    facilement faisable avec SVN,

                    On cite un cas d'utilsation beaucoup plus commun que ne résoud pas simplement un DVCS
                    et bizarrement le mutisme est de mise.
                    http://linuxfr.org/~NoNo/26146.html#904627

                    ou encore comment géré les suavegardes de facon centralisées et

                    La sauvegarde qui est un aspect crucial en entreprise
                    http://linuxfr.org/~NoNo/26146.html#904641

                    La portablité laborieuse de git, un détail


                    C'est vrai On ne peut pas historiser en mode déconnecté, c'est vrai que je reste 6 mois hors de ma boîte et que je commite comme un fou.

                    La complexité de ce genre d'outil n'est qu'un détail insignifiant.

                    Ah au fai,t c'est vrai il y a plein de plugin avec la plupart des outils de tracking, tous les IDEs disposent tous d'une intégration avec SVN au contraire de vos DVCS , preuve tangible que les SVN fanboys ne sont que des moutons de panurge.
                    • [^] # Re: Re:

                      Posté par . Évalué à  2 .

                      bon perso je m'en fous un peu de svn. Git convient a mes besoins si d'autres preferent svn tant mieux pour eux par contre je trouve que tu exageres un peu sur certaines choses comme le fait que git n'existe pas sous windows et que les IDE aient deja des integrations svn et pas git (pour ne prendre que lui), svn a ete developpe depuis combien d'annees? Il y a presque 10 ans que le projet a ete lance. Attend quelques annees avant de comparer le portage sur la pletforme windows et l'integration dans les IDE.

                      Maintenant peut etre que je vais me servir de svn avec le plugin de openoffice.org :)
                    • [^] # Re: Re:

                      Posté par . Évalué à  -1 .

                      C'est vrai On ne peut pas historiser en mode déconnecté

                      Voilà, c'est ça!

                      c'est vrai que je reste 6 mois hors de ma boîte et que je commite comme un fou.

                      Et bien je suis très content pour toi.

                      preuve tangible que les SVN fanboys ne sont que des moutons de panurge.

                      Ce qui est tangible c'est qu'ils voudraient imposer au monde entier leur amour inconditionnel pour un soft...
                    • [^] # Re: Re:

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

                      Concernant les images, chartres graphiques, UML, XML (wtf, vous savez pas merger un xml ? ), je dirai qu'il s'agit surtout là d'un problème humain, de l'incapacité de 5 gars dans un même bureau à se parler alors que des centaines de personnes arrivent à le faire sur des projets libres de tailles importantes. Chercher l'erreur. Alors oui svn permet de mettre un lock technique au manque de communication, mais ce ne résoult guère le problème en général.

                      Sauvegarde de façon centralisé. Euh kékidi ? Il y'a un serveur de référence qui peut être sauvegardé sans problème.

                      Quand à la dernière remarque, Rome ne s'est pas fait en un jour. Git est bien plus jeune que svn, et son intégration dans de nombreux outils va bon train (voir différents post dans ce thread). 2 ans après la sortie de svn, lorsque cvs était encore roi, aurai-tu continuer à utiliser cvs au lieu de svn ?
                      • [^] # Re: Re:

                        Posté par . Évalué à  2 .


                        Concernant les images, chartres graphiques, UML, XML (wtf, vous savez pas merger un xml ? ), ....
                        résoult guère le problème en général.


                        Tout est affaire de point de vue.
                        Bizarrement la technique de l'évitement est aussi de mise chez les prosélytes des DVCS
                        "Ca gère pas mais c'est pas grave."
                        La paille dans l'oeil, la poutre, et tout ce qui s'ensuit.
                        Les projets libres de taille importante gèrent beaucoup moins de fichiers de ce type là qu'en entreprise, donc forcément c'est moins important pour eux. Et si un dev est obligé de refaire le boulot 2 fois, ca n'a guère de conséquence car il ne s'en prendra qu'à lui même et ne rendra de compte à personne.

                        Ca rejoint ma remarque initiale , les DVCS ne sont pas des outils universels et se prêtent beaucoup mieux aux projets communautaires.


                        Sauvegarde de façon centralisé. Euh kékidi ? Il y'a un serveur de référence qui peut être sauvegardé sans problème.

                        Sauf que si un développeur développe une feature pendant un certains temps et ne push pas sa branche par négligence ou ignorance et que son disque crash tout son son travail est perdu.
                        Le dev svn ne perd que son dernier changeset.
                        Ou alors il faut déployer une solution de sauvegarde automatique sur les postes ce qui n'est pas toujours aisé en entreprise

                        Tout repose donc sur la vigilance du développeur


                        Quand à la dernière remarque, Rome ne s'est pas fait en un jour. Git est bien plus jeune que svn, et son intégration dans de nombreux outils va bon train (voir différents post dans ce thread). 2 ans après la sortie de svn, lorsque cvs était encore roi, aurai-tu continuer à utiliser cvs au lieu de svn ?

                        Sur ce point je suis réservé, git est conçu pour Linux et j'imagine qu'il faudra des changements importants pour qu'il soit acceptable sur Windows.
                        Ce sera un frein à son adoption dans les IDEs et autres outils mutli-plateformes.
                        Sur ce point, je suis plus optimiste pour bazaar-ng et mercurial.
                        • [^] # Re: Re:

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

                          Quelques remarques :
                          - je continue à penser qu'il s'agit surtout de problèmes de communications et d'organisations (que j'ai pu constaté par moi-même dans le passé). svn permet ici d'améliorer un peu la situation, mais le problème reste entier

                          - perso, nos $HOME sont backupés, donc pas de soucis particulier. Même quand j'ai travaillé dans une entreprise, avec du Windows, on travaillait toujours sur des disques réseaux backupés. Voir la compétence de vos sysadmins ensuite.

                          - si le développeur est incompétent / négligeant / ignorant, mon premier souci n'est probablement pas celui que tu décris, sachant que les disques durs ca lache pas si souvent que ça. Par contre, svn, git ou hg, j'ai tendance à regarder tous les commits qui passent, et svn n'empêchent pas les commits foireux (avec du code commenté pour les tests pas décommentés, des trucs de débug sans queue ni tête ...).

                          - git est écrit pour Linux, mais tourne concretement sur n'importe quel système Posix. Pour Windows, il reste du boulot, je ne sais pas trop où ils en sont. Je n'ai personnellement pas d'action pour git. Hg, monotone (on l'avait pas encore cité), bazaar-ng ou cie, je n'en ai cure, tant que c'est décentralisé (il se trouve que là ou je travaille, on utilise plus git qu'autre choses).
                          • [^] # Re: Re:

                            Posté par . Évalué à  1 .


                            - je continue à penser qu'il s'agit surtout de problèmes de communications et d'organisations (que j'ai pu constaté par moi-même dans le passé). svn permet ici d'améliorer un peu la situation, mais le problème reste entier

                            SVN résout ce problème complètement:
                            Se prémunir que 2 personnes accèdent concurremment à une ressource.CQFD
                            Nul n'est à l'abri d'un oubli.
                            Que des questions d'organisation subsistent peut -être mais c'est décorrélé du pb qui nous préoccupe.

                            J'aurais préferé que tu nous répondes sur la façon dont tu gérerais ce pb alors je t'aide un peu.
                            1- isoler lorsque c'est possible les fichiers dans une même arborescence (specs, fichier UML) et utiliser une branche partagée lorsque l'outil support le modèle centralisé.

                            2- pour les autres fichiers, déployer des hooks sur chacun de postes (avec le problématiques qui s'ensuivent , portage, droits, ...). Le hook accédera à un serveur central pour gérer l'exclusivité. (Réinventons la roue )
                            Dommage que pour des considérations de securité certains DVCS (hg, git je sias pas) choisissent délibérément de ne pas propager les hooks, du coup c'est aux admins de s'en charger.
                            Ou mieux il pourrait prendre en charge ce ca en natif aavec ses prtopres métadonnées (flag particulier sur un fichier qui indique qu'on doit réserver un fichier sur une archive particulière, debranchable en locaal si nécessaire )

                            En même temps pour quelqu'un qui travaille en mode deconnecté 6 mois durant je comprend que ca ne serve pas. Autant modifier toutes les specs a gogo et tout refaire après. Pas la peine d'implementer ce use case dans un DVCS pour les rares fois où on en a besoin.



                            perso, nos $HOME sont backupés, donc pas de soucis particulier. Même quand j'ai travaillé dans une entreprise, avec du Windows, on travaillait toujours sur des disques réseaux backupés. Voir la compétence de vos sysadmins ensuite.

                            A vi vos espaces de travail sont sur des disques réseaux backupés.
                            Ca aide vachement à travailler en mode deconnecté ca. Il me semblait que c'était l'argument massue en faveur des DVCS.
                            La seule solution est de déployer une solution de sauvegarde automatique à la connexion, ce qui est techniquement plus complexe et nécessite une bonne organisation derrière


                            Par contre, svn, git ou hg, j'ai tendance à regarder tous les commits qui passent, et svn n'empêchent pas les commits foireux (avec du code commenté pour les tests pas décommentés, des trucs de débug sans queue ni tête ...).

                            SVN n'empêche pas non plus de travailler sur de branches parallèles et de confier les merges à une équipe d'intégration qui est chargée d'approuver de ou de rejeter les modification su les branches maître.
                            Le modèle user/team centric est parfaitement applicable
                            • [^] # Re: Re:

                              Posté par . Évalué à  2 .

                              Jusqu'à présent il existe toujours une solution techniquement possible sans s'arracher les cheveux pour résoudre vos cas d'utilisation:

                              Pour les commit locaux ,on dispose des changelist

                              Pour les plus exigeants rein n'empêche de se créer un repository local et avec un peu de scripting, on extrait une arbo et on la remonte dans son dépôt local.
                              Ensuite, on se crée un workspace et on commite autant qu'on veut.
                              Pour peu qu'on dispose d'une branche dédiée sur son dépot central on commite chacune des révisions de son dépot local et le tour est joué.
                              N'importe qui pourra incorporer les changeset commités dans sa propre branche sur le serveur.

                              Une fois le travail fait c'est toujours applicable (ca doit être peu ou pro le principe de svk) mais j'imagine que si c'est si essentiel nul doute qu'on verra emerger une solution de ce type

                              Le bisect, faisable simplement

                              ...

                              Pour mon cas d'utilsation en revanche rien de bien convaincant du coté des DVCS actuels, tant qu'il ne décideront pas de l'implémenter.
                              MAis je ne les connais pas tous.
                              • [^] # Re: Re:

                                Posté par . Évalué à  2 .

                                Pour les plus exigeants rein n'empêche de se créer un repository local et avec un peu de scripting, on extrait une arbo et on la remonte dans son dépôt local.
                                Ensuite, on se crée un workspace et on commite autant qu'on veut.


                                Euh comment dire c'est simple ca comme utilisation... Tu montres tout de meme dans tes posts que tu es un "power-user" de SVN et donc que tu le connais sur le bout des doigts ce qui est le cas pour pas beaucoup de monde, je pense que tu en conviendras. Pour une utilisation ponctuel SVN n'est a mon avis pas le plus simple mais c'est une opinion toute personnelle encore une fois.

                                Enfin bon comme dit plus haut chacun fait ce qu'il veut. Ceux qui preferent les trucs centralise a la SVN ca tombe bien cela existe et les autres (dont moi) qui preferent les trucs simple et non centralise cela existe aussi avec les differents DVCS.

                                C'est possible qu'avec plus ou moins d'effort on arrive au meme resultat que git avec svn. Il n'empeche que git existe a des passerelles avec SVN en particulier (du coup tu dois pouvoir meme melanger le meilleur des deux mondes.)

                                C'est ca qui est bien avec le libre, le choix existe et chacun prend ce qui lui convient le mieux.
    • [^] # Re: Re:

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

      > Si tu es tout seul, un "DSCM" est sans intérêt.
      [...]
      > Je connais mal git et mercurial.

      Peut-être que ceci explique cela. Pour avoir pas mal utilisé git et subversion, franchement, tout seul ou pas, y'a pas photo, git est très loin devant. Rien que pour les perfs, avoir un repository facile 2 fois plus petit en espace disque, et à peu près toutes les opérations courrantes pour lesquelles l'outil répond instantanément, c'est déjà un plus considérable. Après, je pourrais parler des vrais avantages de Git sur Subversion, mais bon ...
      • [^] # Re: Re:

        Posté par . Évalué à  -1 .

        > Rien que pour les perfs

        Franchement, t'es un développeur ?
        Tu pisses 500 000 lignes de code par jour ?
        Ou tu t'amuses à alimenter ta gentoo à coup de checkout ?

        Lorsque je développe, si j'attend 5 minutes subversion dans une journée, c'est vraiment le maximum de chez maximum.
        M'enfin, contrairement à toi je ne pisse pas 500 000 lignes de code par jours ni ne fait un "svn update" de tous les sources installés sur ma bécane.
        • [^] # Re: Re:

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

          Bah, fais un truc :

          alias ls='sleep .5; ls'
          alias cd='sleep .5; cd'

          Bosses avec ça une journée, et tu comprendras ce que je ressent quand j'utilise SVN tout en connaissant Git.

          Sinon, j'ai toujours pas compris le rapport entre les perfs, le fait de bosser seul, ou le checkout de Gentoo.

          Allez, fais-nous rire : tu as utilisé Git combien de temps dans ta vie pour le comparer à SVN ?
          • [^] # Re: Re:

            Posté par . Évalué à  3 .

            C'est vrai qu'on fait autant de cd et ls que d'opération sur le repository. Sur ce coup là c'est de la mauvaise foi intégrale et ce n'est pas avec des arguments de ce niveau que tu vas convaincre qui que ce soit.
            • [^] # Re: Re:

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

              $ cat ~/.zsh-history | grep git | wc -l
              206
              $ cat ~/.zsh-history | grep svn | wc -l
              139
              $ cat ~/.zsh-history | grep cd | wc -l
              298
              $ cat ~/.zsh-history | grep ls | wc -l
              228
          • [^] # Re: Re:

            Posté par . Évalué à  0 .

            > Allez, fais-nous rire : tu as utilisé Git combien de temps dans ta vie pour le comparer à SVN ?

            Je l'ai utiliser très très occasionnellement et j'ai rien fait d'exitant.

            A toi de nous impressionner. Tu utilises Git depuis combien de temps ? Tu tapes combien de commandes Git dans la journée ? 500 ? 2000 ?
            WhaooOO !!!
            • [^] # Re: Re:

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

              J'utilise git depuis environ 1 an, j'ai contribué très peu de code à Git, donc, je serais loin de me classer dans la catégorie « expert ». Mais moi, j'ai vraiment utilisé à la fois Git et SVN (j'ai aussi eu la joie de faire du support SVN auprès de 200 étudiants qui l'utilisaient à plein temps pendant un mois, c'est assez instructif). J'ai aussi fait l'effort d'apprendre à peu près correctement bzr et mercurial, et je connais assez bien GNU Arch (ayant contribué pas mal de code à la branche Bazaar et à Xtla, l'interface pour Emacs).

              Rien d'impressionnant, mais je crois que quand je compare Git et SVN, je sais à peu près de quoi je parle.

              Toi, tu te permet de critiquer Git, alors que de toute évidence, tu ne sais absoluement pas de quoi tu parles, tu ignores tout de cet outil. Je sais bien qu'on est Vendredi, mais si tu pouvais avoir des arguments pour troller, ça serait cool, ça élèverait le débat.
              • [^] # Re: Re:

                Posté par . Évalué à  2 .

                excusez-moi d'intervenir comme cela mais je n'ai toujours pas compris comment fonctionnaient les gestionnaires de version distribué !

                Pour les centralisé comme SVN, je comprends qu'il y a un serveur sur lequel les développeurs synchronisent leur code, mais pour le distribué, comment est-ce que ces données sont redistribuées justement ? C'est un genre de p2p ? Ou alors il y a un serveur qui centralise les contributeurs et leur permet d'échanger les données qui sont uniquement stockées sur leurs ordinateurs et non pas sur ce serveur ?

                Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

                • [^] # Re: Re:

                  Posté par . Évalué à  1 .

                  c'est ca qui est genial avec DSCM, tu peux avoir ta petite branche, ton petit fork a toi d'un projet sur ton pc et tout est conserve dans le repertoire de travail apres si jamais tu veux travailler avec d'autre personnes tu peux mettre ca dans un "repository" qui peux etre un repertoire sur le disque dur ou sur un site web sur lequel ils peuvent se brancher et faire dans leur coin leur modif.

                  Exemple: (Je reprend celui du tutoriel)

                  Bob clone le repository de Alice chez lui
                  il fait des changement et les commit dans son repertoire de travail a lui
                  Alice regarde les changements fait par bob sur le repertoire de bob
                  les appliques ou pas
                  Alice fait ses changements dans son repertoire a elle
                  Bob regarde les changement de Alice dans son repertoire a elle
                  etc....

                  Donc en fait chacun travail sur sa propre branche sans avoir besoin d'etre connecte a un serveur pour faire le moindre commit vu que le commit est locale.

                  D'un autre cote tu veux tout mettre sur un serveur a la facon cvs et bien c'est possible et tu balances les commit de ton boulot quand tu le veux, c'est a dire que tu commit chez toi autant de fois que tu le souhaites et tu envoies sur le serveur uniquement lorsque tu es connecte ou que tu es content de tes changements.

                  Avec un cvs like si tu as pas acces au serveur, tu ne peux pas faire de commit et tu as interet a garder trace de tes changements tout seul ce qui est un peu pas tres pratique avec git c'est lui qui s'occupe de ca. (Enfin ca fait longtemps que je me suis pas servi de cvs du coup je dis peut etre des betises). Mais je dois avouer que j'adore le fait de ne pas avoir un serveur central pour garder mes changements mais un simple repertoire .git dans mon repertoire de travail.

                  De plus, je sais pas si c'est faisable avec svn ne l'ayant jamais utilise, la gestion des branches est ultra-simple et tu peux avoir des branches ou tu t'amuses a tout casser tout en gardant celle qui fonctionne sans avoir besoin de dupliquer le projet.
          • [^] # Re: Re:

            Posté par . Évalué à  4 .

            Question bête: git-svn ne te suffit pas pour ton besoin ? => http://www.kernel.org/pub/software/scm/git/docs/git-svn.html
    • [^] # Re: Re:

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

      Que tu devrais demander en premier à ceux qui vont participer à ton projet. Si tu es tout seul, un "DSCM" est sans intérêt.

      Pas d'accord. Perso, je code tout seul sur un projet. L'intérêt que je vois dans mercurial sur svn par ex, c'est que je peux commiter dans le RER et ensuite envoyer mes commits sur mon serveur via un hg push. En cas de revert, j'ai une granularité plus fine que si je devais commiter sur le dépot svn présent sur mon serveur.

      Faire la même chose avec svn était nettement plus complexe.
      • [^] # Re: Re:

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

        Sans déconner les gars, ça vous arrive de déstresser dans les transports ? Parce qu'à vous écouter, je ne comprends pas que les RER et les avions ne soient pas blindés de geeks avec des portables sur les genoux en train de commiter comme des fous...
    • [^] # Re: Re:

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

      Que tu devrais demander en premier à ceux qui vont participer à ton projet. Si tu es tout seul, un "DSCM" est sans intérêt.

      pas d'accord du tout ! Même si tu est seul, ça peut être intéressant de pouvoir versionner ton projet. Et utiliser quelque chose de très lourd comme subversion, non merci.

      Perso, j'utilise bazaar-ng, car c'est le premier que j'ai utilisé, il permet d'utiliser les dépots svn de manière transparente (donc je n'aurais plus jamais a utiliser svn :) et enfin il dispose d'une version native python.

      Donc, avec subversion, tu dois créer un repository quelque part sur ta machine ou tu as plein de place pour y stocker tout et n'importe quoi.

      Alors qu'avec bazaar (ca doit aussi marcher avec git ou mercurial), je me met dans le dossier que je veux versionner, je tape bzr init et c'est fini. De plus je n'ai pas de problème de cohérence. Les révisions sont stockées au même endroit que ma version de travail, pas dans un repository ailleurs.
      • [^] # Re: Re:

        Posté par . Évalué à  0 .

        Donc le seul interêt c'est que l'étape "créer un repository" est inclue dans l'étape 'créer un workspace' puisque les 2 sont la même chose.
        C'est vrai que créer un repository avec un fs sous SVN c'est super compliqué.

        Ah ouais si après tu veux partager avec d'autres c'est plus facile. tu n'as pas à faire une moullinette pour créer un branche dans un repository partagé et remonté les révision que tu as commité dedans.
        Bon ben si t'es flemmard svk est ton ami (écrit en perl en plus puisque tout le monde aime ça). Tu as le beurre et l'argent du beurre et notamment des plugins d'integration avec la quasi totalité des IDEs et des GUIs à ne plus savoir qu'en faire, une architecture roubuste,c coue pour être portable. Mais ca ne compte pas.

        Sinon pour faire des sauvegardes centralisé du travail de tout le monde dans une entreprise faut avoir confiance en ses employés.
        Gare à celui qui oublie de faire un push de sa branche sur le miroir.
        En cas de crash disque, c'est bon pour la productivité ça.
        Avec SVN tu perds juste le travail en cours que tu n'as pas encore commité.
      • [^] # Re: Re:

        Posté par . Évalué à  0 .

        $ mkdir $HOME/svn
        $ mkdir -p $HOME/svn/$PATH
        $ svnadmin creeate $HOME/svn/$PATH
        $ svn import -m "import initial" $HOME/$PATH file://$HOME/svn/$PATH
        $ svn co file://$HOME/svn/$PATH $PATH


        Et voila. Après du change $PATH par ce que tu veux et l'affaire est pliée.
        • [^] # Re: Re:

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

          Soit tu crée un repository subversion pour chaque projet que tu commence (et comme j'en commence beaucoup, ca veut dire créer beaucoup de repositories ... et pardonne moi, mais je trouve ça un peu lourd)

          Soit je me crée un seul repository dans mon homedir. mais je trouve ça très crade. Car ça veut dire que tous mes projets vont être mélangés. Si un jour j'ai un projet qui grossit, il fera grossir mon repository. Et si mon repository devient trop gros, il pourrait ne plus tenir sur le disque dur de mon laptop et je pourrais le migrer sur mon disque dur externe. Et cela veut dire que pour tous mes projets, je devrais brancher mon disque dur externe (ce que je fais très rarement) ... même si c'est un petit projet.

          Je préfère de loin utiliser bazaar.
          Une des fonctionnalités qui me fait choisir bazaar, c'est justement que tout est stocké dans le même dossier.

          Avant de conaître bazaar, je m'étais fait un dépôt subversion quelque part. Sauf qu'au bout d'un moment je ne savais plus trop ce qu'il y avait dedans, lorsque je regardais son contenu, je ne comprenait rien ... et j'ai fini par l'abandonner.... au profit des commandes RCS ci et co ... et de script shell fait main.

          Je peux comprendre que subversion soit bien pratique dans certains cas. mais dans mon cas (je veux juste avoir un système qui enregistre les révisions de mes fichiers) je trouve subversion trop lourd a utiliser. Cela implique de séparer ton projet en deux endroits (le repository et la copie de travail) ... et aussi, cela t'empêche de facilement sauvegarder un seul projet parmi d'autres sur le repository ... car justement le repository subversion fait un tout qu'on ne peux pas sparer si facilement (il y a surement des moyens, mais ce n'est pas aussi simple qu'un mv).

          Je ne dénie pas les qualités de subversion, je trouve juste qu'il ne correspond pas a mon besoin. Et qu'il y a d'autres logiciels qui correspondent bien mieux.

          Mildred
          • [^] # Re: Re:

            Posté par . Évalué à  0 .

            > Je ne dénie pas les qualités de subversion

            Et j'ai nul part critiquer bazard-ng.

            Mais faut pas pousser non plus. Tu passes ton temps à critiquer subversion sur des conneries. Du genre "tiens, et si ce matin je me faisait un dépôt en 2 secondes juste pour le plaisir de voir que ça prend 3 secondes de moins que Subversion".
            Créer un dépôt est une activité accessoire. Savoir s'il faut en faire qu'un ou deux car une partie sera peut-être indépendante à l'avenir demande de la réflexion. Je passe beaucoup, beaucoup, beaucoup plus de temps à faire des "svn diff", "svn log", fouiller dans bugzilla pour le mettre à jour après une correction de bug et récupérer sa référence pour la mettre dans le log svn qu'a faire des "svnadmin create" le matin. Je fais un "svnadmin ...." pour 50 000 "svn diff|status|commit|update|merge". Et toi ?
            • [^] # Re: Re:

              Posté par . Évalué à  2 .

              Tu as lu son commentaire ?
        • [^] # Re: Re:

          Posté par . Évalué à  4 .

          ah oui simple et tres portable... Euh oui c'est ironique

          J'ai jamais aime cvs avec pour raison principale le fait de devoir un serveur pour le bousin et etre totalement dependant de ca.

          Un truc que j'ai trouve genial avec git c'est que je veux commencer un projet:

          mkdir monproject
          cd monproject
          git init

          et voila c'est fait pas besoin d'autre chose. Le truc encore plus top c'est que par exemple, j'ai la flemme de prendre mon portable pour aller chez mes parents (qui n'ont pas internet) mais j'ai un truc important a finir. Je prend ma petite cle usb je copie le repertoire du projet dessus, je branche la cle sur le pc de mes parents et je peux continuer a introduire les revisions comme je le souhaite.

          Cela permet aussi d'avoir un backup physique des revisions vu qu'il suffit de sauver le repetoire du projet. Enfin je m'en sert probablement mal, pas de facon optimale mais il convient a mes besoins a moi car ca marche point barre et c'est ultra simple (surtout avec git-gui...)
  • # Mes 2 centimes

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

    Déjà, il faudrait être bien sur qu'un DSCM est ce qui est le mieux adapté à tes besoins. Les DSCM deviennent à la mode mais posent également des problèmes d'organisation. Ce n'est plus le logiciel qui centralise, mais une personne : tout le monde doit en être conscient. Il y a des projets vraiment communautaires, ou simplement avec plusieurs mainteneurs de "même poids", qui n'accepte pas cette philosophie. L'autre point, technique, est qu'avec un DSCM, tu auras plus de conflits à gérer qu'avec un SCM classique. Chaque personne pouvant faire sa sauce chez lui, cela complique les fusions de code.

    Cela dit, que choisir entre Git et Mercurial ?

    C'est probablement plus une affaire de gout qu'autre chose.

    Pour ma part, j'ai choisi Git depuis un moment déjà. Il était plutôt complexe à utiliser directement à ses débuts mais il a fait d'énormes progrès dans le domaine. Pour moi, Git a passé l'épreuve du feu. Avoir été choisi pour gérer le kernel Linux, Xorg ou Wine est une preuve indéniable de qualité originelle, ou du moins acquise. De nombreux projets et forges l'on choisi. C'est rassurant : s'il y a des bugs, ils seront vite repérés et corrigés. D'autre part, les outils tiers se développent effectivement.

    La critique que je ferai sur Git est le fait qu'il soit difficile de remonter dans l'historique d'un fichier. Le modèle de gestion est plutôt basé sur l'historique de tout l'arbre des sources par patches. Si tu veux suivre un seul fichier, c'est donc un peu compliqué. Si tu veux suivre l'évolution de ton projet dans sa globalité, c'est simple.

    Je connais très mal Mercurial, je ne vais donc pas en parler ici. Je ne l'ai pas choisi car je ne suis pas très fan de Python (surtout sur un serveur) et je n'ai pas très bien compris l'intérêt de l'utiliser pour coder un DSCM sachant qu'on peut très bien faire sans. Mais bon, l'égout et les couleuvres...
    • [^] # Re: Mes 2 centimes

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

      Effectivement, il semble que Git soit en train de gagner du terrain par rapport à Mercurial, et son utilisabilité s'est bien améliorée dans les dernières versions.

      Un point qui reste bien différentiateur est le support Windows, sous lequel Mercurial marche très bien, alors que pour Git il y a un écart sensible par rapport à la version Linux.

      (Moi j'utilise un peu les deux pour mes projets perso.)
    • [^] # Re: Mes 2 centimes

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

      > Je ne l'ai pas choisi car je ne suis pas très fan de Python (surtout sur un serveur) et je n'ai pas très bien compris l'intérêt de l'utiliser pour coder un DSCM sachant qu'on peut très bien faire sans.

      Mais git utilisant perl ne te choque pas ?
      • [^] # Re: Mes 2 centimes

        Posté par . Évalué à  4 .

        > Mais git utilisant perl ne te choque pas ?

        Puisque l'utilisation de python le choque, il est normal que l'utilisation de perl ne le choque pas.
        • [^] # Re: Mes 2 centimes

          Posté par . Évalué à  1 .

          Git écrit en perl, c'est une blague ...hein ?
          • [^] # Re: Mes 2 centimes

            Posté par . Évalué à  1 .

            Le noyau est en C. Les wrappers, eux, sont partagés entre shell et perl.
            19 perl pour 54 shell au moment où je compte.
            • [^] # Re: Mes 2 centimes

              Posté par . Évalué à  1 .

              Qu'entends tu par wrapper ?

              Est ce je peux utiliser Git simplement en appelant que des fonctions noyau.

              Sinon ca me rappelle la première version de CVS en shell sur laquelle un fork avait été fait pour tout réécrire en C.
              Ou encore ces infâmes hacks de Tom Lords sans queue ni tête qui ont données naissance à toutes cette ribambelles de forks mieux concus.

              Vive Mercurial et Python alors.
              Ou encore SVN écrit entièrement en C en se basant sur l'apache Portable Library à des fins de portabilité.
              Ca en est où git avec windows à propos ?
              Pas facile de rendre un portage aussi performant lorsqu'il n'a pas été prévu pour à la base.
              Python aussi est portable.
    • [^] # Re: Mes 2 centimes

      Posté par . Évalué à  3 .

      Je connais très mal Mercurial, je ne vais donc pas en parler ici. Je ne l'ai pas choisi car je ne suis pas très fan de Python (surtout sur un serveur) et je n'ai pas très bien compris l'intérêt de l'utiliser pour coder un DSCM sachant qu'on peut très bien faire sans. Mais bon, l'égout et les couleuvres...

      Parce que c'est plus rapide pour developper, que un scm bien foutu est très vite IO-bound (le core de mercurial est en C, le reste est en python, au final c'est pas si différent de git, sauf que le core est plus petit :)

      Sinon perso mon problème avec git c'est le fait qu'il n'y ait pas d'historique au niveau fichier et que la taille prise par le dépot (j'aime pas l'architecture avec d'un coté on a un truc très gros de l'autre on a des packs qu'il faut faire manuellement et qui peuvent potentiellement etre dangereux pour l'historique -- on reecrit l'historique).
      Dans mercurial je suis pas très fan de la gestion des branches (in-repo) si on utilise que des clones pour developper ses branches ca rox (et avec les hardlinks ca prend pas trop de place).

      (D'ailleurs mercurial est aussi utilisé par des "grands": mozilla, sun, xen, etc)
  • # cogito

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

    A tout hasard, je me permet de te mettre un truc trouvé par hasard en jouant avec openmoko : cogito ( http://git.or.cz/cogito/ )

    C'est une interface simplifiée à Git, ça semble intéressant.
    • [^] # Re: cogito

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

      Git a fusionné les fonctions de Cogito depuis plus d'un an. Ce projet ne sert plus a grand chose et n'est plus développé. Git a une interface simplifiée maintenant.
      • [^] # Re: cogito

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

        merci pour l'info, je connais pas du tout git mais j'ai vu passé ce package. Voilà, c'était juste une tentative (dérisoire ) pour me rendre utile
    • [^] # Re: cogito

      Posté par . Évalué à  2 .

      cogito est reputé obsolète et non maintenu. Cf http://git.or.cz/#tools
  • # Idées fausses

    Posté par . Évalué à  10 .

    Salut !

    Je me permet de corriger quelques idées fausses véhiculées dans ton journal :

    Depuis les annonces de Mozilla et OpenSolaris, je ne crois pas avoir croisé beaucoup de projets qui utilisent Mercurial

    Sur la page d'Accueil de Mercurial on peut lire :
    2007-12-12 NetBeans migrates to mercurial
    2007-12-05 OpenJDK (aka Java) switches to Mercurial
    2007-11-10 AsciiDoc has switched from Subversion to Mercurial
    2007-04-20 Xine has switched from CVS to Mercurial.

    Franchement du point de vue "qui a le plus de gros projets qui ont migré vers moi" Git et Mercurial sont équivalents.

    je connais des hébergeurs spécialisés dans Git comme GitHub, mais pour Mercurial, je ne pense pas en avoir croisé.

    Je reconnais qu'il y a moins d'hébergement Mercurial que Git, mais il y en a. http://sharesource.org/ est un bon exemple. De plus, comme Git, Mercurial permet d'avoir des dépôts en static http : tu peux très bien héberger ton projet sur tes pages persos de free.fr par exemple.

    On pourrais blablater pendant des heures, mais à notre petit niveau comme au niveau de gros projets Git et Mercurial sont équivalents sur leurs fonctionnalités et leurs performances. Choisir l'un ou l'autre est une affaire de goût, c'est comme choisir entre zsh et bash, perl et python, c++ ou java (je caricature évidemment).

    Cependant je crois que tu te trompes très fort en pensant que Git va écraser la concurrence et détriment du développement de Mercurial. En fait ils vont cohabiter : le noyau Linux par exemple a un dépot Mercurial synchronisé avec le dépot Git ...

    Lequel choisir alors ?

    C'est pas moi qui vais répondre à la question c'est toi, selon tes critères, tes projets et tes utilisateurs !
    En ce qui me concerne, tu l'auras deviné, j'ai choisi Mercurial après avoir longtemps testé les deux.

    Les raisons principales ont été la simplicité (il n'y a pas photo à mon avis, depuis les docs jusqu'à l'utilisation quotidienne), et la portabilité (je travaille avec des gens qui sont sous diverses platformes dont Windows, Linux et Mac OS).

    Pour les allergiques à Python, je dirais une seule chose : Python ou pas, regardez la qualité du code de Mercurial et sa petite taille comparé au mammouth qu'est déjà Git. Pour moi c'est un gage de qualité, maintenabilité et extensibilité. Après qu''il soit en Python, Eiffel ou n'importe quel language à la mode m'indiffère !
    • [^] # Re: Idées fausses

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

      Totalement d'accord, à part le "n'importe quel language à la mode m'indiffère" .. J'ai vécu des installs bien longues et pénibles avec darcs (en haskell). Au moins avec mercurial aucun souci c'est du bon vieux python qui tourne sur n'importe quelle version 2.x
      • [^] # Re: Idées fausses

        Posté par . Évalué à  3 .

        C'est vrai que l'aspect "installation" est important : au boulot on a une vieille Suse Linux Entreprise sur laquelle bien évidemment je n'ai pas les droits root.
        Et bien j'ai installé Mercurial sur mon compte en local très facilement sans aucune dépendance à gérer et grace à la "per user installation" : http://www.selenic.com/mercurial/wiki/index.cgi/UnixInstall#(...)

        Un vrai régal !
    • [^] # Re: Idées fausses

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

      je rajouterai que si on bosse sur un projet qui est "multi-plateforme", le choix d'un DCSM est crucial, et cela l'a été pour Mozilla. Et Mercurial l'a emporté sur GIT pour ce critère notamment chez Mozilla, parce qu'il était bien supporté sur mac et windows (puisqu'il y a beaucoup de contributeurs sur ces plateformes, et pas seulement sur linux)

      Autre chose, la documentation et la simplicité : c'est un point aussi important. les DCSM ayant une logique pas forcément simple à comprendre (surtout si on a beaucoup utilisé CVS ou subversion), il faut que la doc soit complète et pédagogique. C'est d'autant plus vrai si on veut attirer des contributeurs de tout horizons et de tout niveaux.

      Sinon je rejoint chicha : non mais franchement, qu'est ce que ça peut faire pour un utilisateur que le logiciel machin soit fait en python ou C ?
    • [^] # Re: Idées fausses

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

      Enfin quelqu'un qui traite du sujet du journal.

      De mon côté, je me suis posé la même question. Et j'ai choisi Mercurial pour les critères suivants :
      - marche sous linux et windows comme un charme
      - la doc est très bien foutue, prise en main instantanée de mon côté
      - doc imbitable côté git

      Critères subjectifs mais importants (c'est une hérésie de croire que les humains font des choix "objectifs" ) :
      - j'aime bien python
      - à la lecture de la doc, j'ai bien aimé la philosophie développée par les développeurs : un outil simple et compréhensible
      - a contrario, j'ai pas trop aimé l'approche de Linus : je fais le coeur, démerdez-vous avec des scripts shell et perl pour que ca ressemble à un SCM
      - j'ai lu plein de fois les docs sur git, je comprends toujours pas le 10e des fonctions ni de comment ça marche. J'ai lu une fois la doc sur mercurial et j'ai tout compris, à la fois sur les fonctionnalités et sur le coeur.
      - une boite s'est montée autour de mercurial. Ca veut dire qu'ils ont des contraintes, genre outil bien documenté, stabilité sur plusieurs environnements, etc. Linus au contraire a dévéloppé un truc imbitable en imposant son fonctionnement à tout le kernel. Il n'a pas besoin que git soit simple à utiliser (il est plutôt pour l'élevation des barrières d'entrée sur la contribution au kernel). C'est donc les autres qui ont du se farcir le sale boulot de rendre git approchable. Cette différence d'approche rend mercurial plus convivial.
      - hg c'est plus court à taper que git

      Globalement, à part le truc de windows et le fait que git marche plus vite pour des projets énormes, je pense qu'ils se valent tous les deux et que donc le choix de l'un ou de l'autre est subjectif.
  • # Interface

    Posté par . Évalué à  3 .

    Et d'un point de vue des interfaces tout-en-un à la trac, quels outils existent pour ces DSCM ?
  • # Git par rapport à SVN

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

    Je suis utilisateur quotidient de Git et subversion, je ne connais pas Mercurial. Je constate beaucoup de commentaires par rapport à l'utilité de Git par rapport à Subversion. Voici un tout petit exemple qui simplifie extrêmement ma vie avec git.

    Les branches, je peux merger à n'en plus finir entre toutes mes branches sans me poser de questions car git garde l'historique des branches et ne va donc pas appliquer plusieurs fois des changements.

    $ git branch
    betterhtml
    filterabstracts
    htmltolatex
    * local
    master

    J'ai 3 branches de travail, une local et une master que j'utiliser pour pousser ma version finale vers mon serveur:

    $ git push monserveur master

    Par exemple ma branch htmltolatex est une branche que je traine depuis longtemps car bon, l'implementation est longue. Quand je retravaille dessus, je fais juste un :

    $ git pull local

    Cela m'assure que tous les changements de ma branch local sont maintenant dans ma branche htmltolatex, je bosse dessus, je commit et je retourne vers mes autres fonctionnalités.

    Quand j'ai un petit bug à fixer, hop, je fais une branch depuis local, je fixe, commit, merge dans local et master, push master sur le serveur, et retourne sur mes autres branches. Un petit pull pour reprendre les changements dans ma branch et je continue le boulot.

    Et comme git-svn fonctionne très bien, je peux utiliser git même si en face il y a un dépôt subversion. Sinon les fonctionnalités avancées, je n'ai pas trop testé. Je trouve simplement très pratique de ne pas avoir besoin d'être "en ligne" pour faire mes commits.
  • # Avis perso

    Posté par . Évalué à  -4 .

    La centralisation de SVN m'est irritante.

    Mercurial est pour ce qu'en sait une copie de GIT en python. Pour ma part, j'aime pas avoir des langages de haut niveau dans autre chose que des user applications.

    Je trouve GIT très élegant. Un fois les concepts maîtriser... c'est beau.

    Bref, GIT c'est beau, ça marche du tonnerre, c'est en C et sa license est la GPL.
    • [^] # Re: Avis perso

      Posté par . Évalué à  3 .

      "mercurial hg" est très bien, moins connu que git (linus effect) mais bien quand même.

      et un gestionnaire de version est une application utilisateur.
    • [^] # Re: Avis perso

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

      > Mercurial est pour ce qu'en sait une copie de GIT en python

      Pas du tout ! git est une copie de mercurial en C
  • # Pour les Subversion fanboys

    Posté par . Évalué à  1 .

    J'ai deux cas où SVN me semble pourri:

    1) un dossier et les fichiers qu'il contient doivent être renommés.

    XXX_pouet/
    + XXX_pouet.h
    + XXX_pouet.cpp

    Et je veux:

    XXX/
    + pouet.h
    + pouet.cpp

    TortoiseSVN m'oblige à le faire en deux fois, avec un commit intermédiaire...

    2) Je veux fusionner depuis une branche, mais les fichiers ont été déplacés/renommés dans le trunk. TortoiseSVN me répond systématiquement "skip missing target"...

Suivre le flux des commentaires

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