Journal Mercurial ou GIT

Posté par  .
Étiquettes : aucune
0
10
août
2010
Bonjour

Je travaille beaucoup avec SVN et CVS sous linux, essentiellement avec eclipse. J'aimerais beaucoup passer à un vrai gestionnaire de version. J'ai déjà utilisé GIT sur des projets, et j'adore énormément, néanmoins, l'omniprésence de la ligne de commande me gène beaucoup. Je suis un adepte du concept "une GUI pour les dominer tous". Une GUI bien léchée pour moi est avant tout le moyen le plus efficace et surtout de ne pas commettre d'erreur.

Merci de ne pas tomber dans le troll "mais la ligne de commande est plus efficace pour les 12000 raisons suivantes". Je ne VEUX pas de ligne de commande, je veux un outils "tu cliques tu pointes". La gestion de conf doit etre le plus simple, efficace et transparent pour moi.

Mercurial, je connais pas, mais j'ai l'impression qu'au niveau fonctionnel on est à peu près au même niveau que GIT (bon, le stash/index manque, peut etre 2 3 autres fonctions sympathiques, n'empeche que l'essentiel est là).
Et l'essentiel pour moi c'est:
- brancher, merger, etc de manière transparente dans mon travail. Un bouton pour commiter, une boite de dialogue pour remplir le log, un historique pour regarder les version, un outil de comparaison pour vérifier les changement, et un outil de merge automatique, voilà tout ce qu'il me faut
- j'ai vraiment beaucoup beaucoup de mal avec gitk ou git gui. En théorie oui ca marche, mais dans la pratique, je n'arrive pas à l'utiliser. La vue en historique est limitée à la branche actuelle par défaut (c'est stupide, s'il y a plusieurs branche, j'ai besoin de toute les voir, s'il y en a trop, on peut afficher que les dernières actives,...). J'utiliserais bien qgit, mais pareil, il manque des outils de merge efficace.

De manière générale, je trouve que tous les GUI se ressemblent, mais aucun ne propose de faire le boulot comme il faut. A chaque fois je me dit "bon, très bien, je vois l'historique, mais comment je sors cette version particulière", ou "je voudrais tagger cette version ou créer une branche à partir de là, comment je fais?" ou (le plus souvent) "comment je merge?". Bref, aucun ne me semble suffisament mur pour ne pas retomber sur la ligne de commande. Que ces outils utilisent la ligne de commande en interne ne me dérange pas, mais je ne VEUX pas avoir affaire à cette bestiol là. Je l'utilise assez souvent pour me dire que plus je m'en passe, mieux je me porte.

Eclipse avec son projet "egit" me semble très prometteur. Ces développeurs là on compris qu'un outil doit être le plus intégré possible. Mais l'outil git ne sera pas mur avant l'année prochaine (pas d'historique, pas d'outil de merge pour l'instant). Pour l'instant, j'utilise CVS donc c'est assez limité, mais suffisant. Pour SVN, avec collabnet merge utility on peut merger des branches SVN, c'est pas mal tu tout, mais il faut choisir les commits sur la branche à commiter (mon repo est en SVN < 1.4). Moi ce que je veux c'est "prend cette branche et applique là sur le trunk". Point bar.

Le but a terme est de convertir des collegues de bureau pour qui la notion de branche est déjà source d'erreur possible, ils sont habitué à un développement très linéaire (on commit tous dans la HEAD, yohooo!!!) il faut que je le sorte un "workflow", simple, efficace, fonctionnel, et surtout, sans source d'erreur.

Donc, voilà, dans l'état actuel des connaissances, est ce que GIT ou Mercurial sont "murs" pour mes cas d'utilisation?

Merci pour vos remarques!

  • # Git…

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

    Git a des interfaces graphiques. Personnellement, je ne m'en sers que de façon auxiliaire, pour visualiser l'historique de façon graphique, par exemple. J'aime bien gitg, dans le genre : [http://trac.novowork.com/gitg/].

    • [^] # Re: Git…

      Posté par  . Évalué à 5.

      mercurial à des interfaces graphiques aussi.
      j'utilise hgtk qui est très bien et qui est plus ou moins lié à tortoise (je sais pas à quel point) => iIHM unifiée sous Windows et sous Linux ce qui est bien pour du dev multiplateforme.

  • # gitk --all

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

    Pour voir toutes les branches avec gitk: gitk --all

    • [^] # Re: gitk --all

      Posté par  . Évalué à -6.

      ligne de commande.

      • [^] # Re: gitk --all

        Posté par  . Évalué à 3.

        Rhooooooooooooooooooooooooooooooooooooooooooo et rho
        Tu te fais un p'tit .desktop qui lance gitk --all au lieu de gitk.
        Mais arg! éditeur de text /o\

        • [^] # Re: gitk --all

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

          Ou alors, tu te poses la question « By jove, que peut donc bien faire l'entrée "Visualize all branch history" du menu "Repository" de git gui ? ».

          Ou alors, tu regardes dans le menu « View » de gitk, tu trouves « New view », et tu cherches la/les cases à cocher qui vont bien.

          Je connaissais gitk --all, mais pas leurs équivalents graphiques, il m'a fallu plus de temps pour rédiger ce message que pour trouver les options. Bref, l'auteur du journal n'avais pas très envie de trouver visiblement.

          • [^] # Re: gitk --all

            Posté par  . Évalué à 1.

            je connais. Mais ce n'est pas pratique d'aller dans un menu constament alors que ça devrait être fait par défaut. C'est toujours la question d'ergonomie : une option cachées dans un menu/sous menu qui est constament utilisée n'a rien à faire dans un endroit aussi innaccessible.

            Et gitk/git gui sont pas mal pour faire du commit simple, mais dès que tu veux aller un peu plus loin tu retombes dans la ligne de commande.

            Et surtout, une interface graphique avec des bouton et des champs partout n'a aucun intéret par rapport à la ligne de commande. Il faut une interface propre, orientée processessus (quand je pars dans une session de merge, je ne veux pas voir tout ce qui concerne la création de tag).

  • # Sans lever le troll ...

    Posté par  . Évalué à 4.

    Je suis un adepte du concept "une GUI pour les dominer tous". Une GUI bien léchée pour moi est avant tout le moyen le plus efficace et surtout de ne pas commettre d'erreur.
    sans lever le troll : tu commets une grave erreur. Je n'ai rien contre les GUi lorsqu'ils sont utilisés à bon escient. Il y a de nombreux cas ou utiliser un GUi n'apporte rien, et est contre productif. Maintenant si tu préfères un GUI dans ce cas, je ne te jugerai pas, mais sache que dans de nombreux cas un GUI ne sert à rien.
    De manière générale, je trouve que tous les GUI se ressemblent, mais aucun ne propose de faire le boulot comme il faut.
    Passe en ligne de commande ... :)

    Sinon à mon avis, Git et Mercurial sont fonctionnellement très proches. Cependant il me semble que Mercurial est plus avancé dans la gestion des dépots via http/https : ça ressemble plus à SVN de ce côté. Avec git je ne pense pas qu'on puisse utiliser HTTP/HTTPS pour envoyer les modifs d'un dépot local vers un dépot distant (ou alors il y a une bidouille).

    • [^] # Re: Sans lever le troll ...

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

      Cependant il me semble que Mercurial est plus avancé dans la gestion des dépots via http/https : ça ressemble plus à SVN de ce côté.

      Exact, mais qu'est-ce que ça apporte au juste ?

      Git a deux modes de transmission principaux : la publication en lecture seule via son protocole natif, et l'envoi via SSH.

      Avec git je ne pense pas qu'on puisse utiliser HTTP/HTTPS pour envoyer les modifs d'un dépot local vers un dépot distant (ou alors il y a une bidouille).

      Si, ça se fait très bien, mais ce n'est pas super bien intégré. Le transport HTTP de Git est clairement un palliatif quand on ne peut utiliser ni le protocole natif, ni SSH.

      • [^] # Re: Sans lever le troll ...

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

        Git gère depuis longtemps les dépots distants sur serveurs WebDAV (extension de HTTP, non-spécifique à Git), mais c'est un peu une bidouille : il n'y a pas d'intelligence sur le serveur, donc c'est largement moins efficace.

        Plus récemment, Git a appris un protocole « smart HTTP », comme ce que Mercurial savait faire depuis longtemps : un protocole spécifique à Git (avec script CGI côté serveur) plus efficace. Le principal intérêt par rapport à SSH étant d'être plus firefall/proxy-friendly.

        Mercurial a eu de l'avance sur ce point, mais je ne pense pas qu'il reste de différence notable aujourd'hui.

      • [^] # Re: Sans lever le troll ...

        Posté par  . Évalué à 2.

        Exact, mais qu'est-ce que ça apporte au juste ? passer au travers d'une config firewall un peu trop restrictive.
        Si, ça se fait très bien, mais ce n'est pas super bien intégré. Le transport HTTP de Git est clairement un palliatif quand on ne peut utiliser ni le protocole natif, ni SSH.

        Ca arrive plus souvent qu'on ne le croit.

    • [^] # Moi aussi je veux sauver les trolls qu'on essaye de tuer dans l'œuf

      Posté par  . Évalué à 2.

      Je n'ai rien contre les GUi lorsqu'ils sont utilisés à bon escient. Il y a de nombreux cas ou utiliser un GUi n'apporte rien, et est contre productif

      Ben oui, mais il y a aussi de nombreux cas ou les GUI sont bien plus productives... et justement il se trouve que c'est particulièrement le cas avec CVS ou SVN. Utiliser par ex. Tortoise avec un outil de diff graphique est sans le commencement du début du millième d'une comparaison possibe avec des outils en ligne de commande exclusivement. « N'avoir rien contre » n'est pas suffisant. Il faut savoir reconnaître leur absolue supériorité dans ces cas là.

  • # plop

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

    > au niveau fonctionnel on est à peu près au même niveau que GIT (bon, le stash/index manque, peut etre 2 3 autres fonctions sympathiques, n'empeche que l'essentiel est là).
    oué, enfin sauf les branches locales nommées sous git qui n'existent pas sous mercurial (oui je sais, il y a des extensions mais j'ai jamais retrouvé ce qu'il y a sous git)

    Sinon, pour la GUI : le problème c'est que les cas sont nombreux, complexes, donc pour faire un gui propre et complète pour git / mercurial c'est compliqué. Si on rajoute en plus le support d'extensions (dont certains sont indispensables, comme stgit) ça devient le bordel.
    Donc, peut-être qu'un jour egit sera potable, pour le moment il ne sert pas à grand chose...

    > Pour l'instant, j'utilise CVS donc c'est assez limité, mais suffisant
    toutes mes condoléances

    > mon repo est en SVN < 1.4
    si en plus tu t'amuse avec des trucs obsolètes ;)

    > ils sont habitué à un développement très linéaire (on commit tous dans la HEAD, yohooo!!!) il faut que je le sorte un "workflow", simple, efficace, fonctionnel, et surtout, sans source d'erreur.
    ouch !
    heu ...
    bon courage ;)

    Je bosse avec svn + git-svn, autour de moi on a du svn, des branches ... ben c'est déjà pas évident d'envisager une migration git (essentiellement pour les raisons de GUI) donc si les dev n'utilisent pas du tout les branches, c'est po gagné (mais si ça marche je veux bien la recette ;))

    As-tu regardé du côté de bazaar ? Les perfs sont assez désastreuses, mais c'est assez bien foutu et pour une migration cvs/svn vers un dcvs c'est très intéressant.

    Quelques liens pour compléter (et pour relever le niveau de mon message...) :
    - Bazaar workflows [http://wiki.bazaar.canonical.com/Workflows]
    - A successful git branching model [http://nvie.com/git-model]
    - a guide to branching in mercurial [http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me(...)]
    - mercurial workflows: branch as needed [http://stevelosh.com/blog/2010/02/mercurial-workflows-branch(...)]
    - mercurial workflows: stable & default [http://stevelosh.com/blog/2010/05/mercurial-workflows-stable(...)]

    -bonus : [http://stevelosh.com/blog/2010/02/my-extravagant-zsh-prompt/]

    • [^] # Re: plop

      Posté par  . Évalué à 1.

      A propos du développement directement sur le trunk, à noter que dans bien des cas c'est la solution la plus adaptée.

      Dans mon cas, on bosse sur un serveur de base de données propriétaire. Comme les coûts de licence sont élevés, tous les développements se font sur la même base, avec comme conséquences :
      1) la base qui est régulièrement cassée par un nouveau développement en cours de test
      2) le besoin de se synchroniser très souvent sur une base commune à tous

      Du coup, créer des branches de dev ne nous serait d'aucune utilité.

      • [^] # Re: plop

        Posté par  . Évalué à 2.

        j'aime faire des commits de mes dev au cours de la journée pour pouvoir revenir sur des version antérieur du fichier, sans pour autant poluer le trunk avec des dec pas completement terminé.

        Trunk => doit toujours compiler.

        Mes petites branches de dev ne me genent pas, mais avec CVS ou SVN, impossible de renommer un fichier en gardant l'historique. Innadmissible.

        Cela dit, SVN est pas mal, surtout intégré avec trac. Mais la gestion des dossiers est calamiteuse et les tags ne sont pas de vrai tag sans des hook à la c...

        • [^] # Re: plop

          Posté par  . Évalué à 1.

          surtout intégré avec trac

          git aussi et je crois que pour mercurial c'est pareil.

        • [^] # Re: plop

          Posté par  . Évalué à 2.

          Je comprends bien, mais quand tu as une base partagée, que tu as modifié une procédure stockée, certes ton exécutable va compiler, mais il ne peut plus s'exécuter de toute manière -> impossible de faire des tests tant que le "coupable" n'a pas commité dans une branche commune à tous.

          D'où ma remarque sur : "créer des branches de dev n'est pas toujours utile/adapté".

          Sinon, aux dernières nouvelles SVN sait renommer un fichier en gardant l'historique, non ? C'est une des raisons pour lesquelles il a été développé, en remplaçant de CSV qui lui ne savait pas le faire.

        • [^] # Re: plop

          Posté par  . Évalué à 4.

          J'ai toujours utilisé SVN avec tout le monde dans le trunk, en pensant que les branches servaient à maintenir plusieurs versions différentes et pas plusieurs développeurs...

          Forcément on évite de commiter du code à moitié terminé et on se sépare les tâches pour ne pas tous bosser sur le même fichier en même temps, mais ça marche plutôt pas mal.

          La feature "pouvoir commiter son propre truc perso", c'est justement ce qui me semble relever de GIT (ou autre décentralisé) plus que de SVN pour qui c'est justement une vraie limitation.

          En changeant de boîte, j'ai vu qu'ils faisaient une branche pour chaque dév, ça me semble quand même assez crado de faire chacun dans son coin puis merger tout à la fin avec une liste de conflits longue comme le bras.

          Donc est-ce que j'ai vraiment tout faux depuis le début ?

          • [^] # Re: plop

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

            en fait, le problème est là : on évite de commiter du code à moitié terminé et on se sépare les tâches pour ne pas tous bosser sur le même fichier en même temps

            Déjà, éviter de commiter du code est la pire connerie possible. Souvent ça se termine par quelques cas de figures :
            - le code n'est de toute façon pas commité
            - ça dure trop longtemps, comme il n'y a pas d'historique c'est galère de savoir ce qui a été fait, refait, défait, etc
            - un bug, une tâche ou une demande impromptue arrive, comme c'est pas commité mais qu'on veut pas tout perdre on fait les deux en même temps et c'est la merde
            Ensuite, séparer les tâches ok, séparer les fichiers ... c'est juste une limitation de svn, car il n'y a pas besoin, nécessité avec un vrai gestionnaire de source.

            Evidemment si tout le monde à sa branche et fait nimp, ça déconnera lors des merges. De l'autre côté, avoir sa branche n'empêche pas de bien séparer son taff donc il n'y a pas de prob normalement (et beaucoup de conflits sont gérés par le dcvs, c'est leur force de se baser sur le merge comme opération de base)

            > j'ai vraiment tout faux depuis le début ?
            non, point.
            Mais il y a beaucoup mieux et productif à faire !

            Voir par exemple les liens que j'ai donné plus haut, ça ne parle pas forcément de 1 branche par dev, mais c'est des pistes intéressantes.

            Le principe des dcvs c'est en gros : tu commit tout le temps, chaque truc, tu ne perd jamais l'historique, et ensuite tu merge et tu passes à la suite (vu que le merge est simple tu passes pas 3 plombes dessus)

            • [^] # Re: plop

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

              > tu commit tout le temps, chaque truc, tu ne perd jamais l'historique

              Pas seulement. Tu peux aussi nettoyer ton historique avant d'envoyer, et donc tes conneries intermédiaires restent privées (mais tu les avait quand même commitées en local), tu n'embêtes pas le reste du monde avec. C'est pas toujours souhaitable, mais c'est quasi-indispensable dans un contexte où la revue de code est importante.

              • [^] # Re: plop

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

                Il est vrai que pour ça j'utilise énormément stgit [http://www.procode.org/stgit/] ce qui fait finalement que je réalise se nettoyage avant de réellement commiter
                mais le principe est bien là

                En gros, les dcvs ça ne sert pas forcément (le D j'entends) mais les gestionnaires de sources un tant soit peu évolués (basés sur le merge, commit locaux, etc) sont maintenant indispensables pour moi.
                Si j'avais l'équivalent sans le côté pleinement distribué je l'utiliserai quand même (bien que le côté distribué soit intéressant, même dans de petites équipes)

            • [^] # Re: plop

              Posté par  . Évalué à 1.

              Bien séparé son travail est stupide, quand on touche du code en profondeur on impactera forcément le travail du copain. Le tout c'est de résoudre les conflits rapidement, efficacement, et surtout, une seule fois.

              Ce qui m'énerve avec SVN ou CVS, c'est parfois, ma branche diverge, je me mets à jour avec le trunk, il y a des conflit, je gère je règle. Puis je continue. Je me remet à jour. Et tous mes conflits déjà résolu réapparaissent. Parce que je n'ai pas le bon nombre de commit, parce que je n'ai pas telle extension SVN ou pour une raison X ou Y, le truc ne se fait pas comme il faut et il faut recommencer. C'est inadmissible.

              Je suis habitué à développer dans ma branche pour effectué des petits tags intérmédiaire (tel truc fonctionne maintenant, etc) avant de commiter. Le développement incrémentiel est indispensable. Mais je ne VEUX pas perdre du temps dans un merge alors que le logiciel a toutes les informations (ou devrait l'avoir) pour le faire comme il faut.

              Le coté décentralisé ne m'attire pas plus que ça au final, on reproduira un comportement centralisé (un golden repository chez qui tout le monde commit). Et ça me gene même un peu, le fait qu'une personne ne puisse pas facilement prendre ta branche comme du dit "prend ma branche de dév truc_machin, il faut configurer un "remote, ...". Complexe.
              Mais le merge de git, j'ai gouter, j'ai vu, et je veux la même chose à la maison !

              • [^] # Re: plop

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

                > prend ma branche de dév truc_machin, il faut configurer un "remote, ...". Complexe.

                Tu n'as pas besoin de configurer un remote pour accéder à une branche. Tu as besoin de ça pour accéder à un autre repository. Mais rien ne t'empêche d'avoir plusieurs branches dans le même repository git.

                • [^] # Re: plop

                  Posté par  . Évalué à 1.

                  pas s'il est chez le copain.

                  tu créé tes branches en local. Tres bien. Mais il faut rajouter une étape, "push" pour envoyer ta branche sur le repo "centrale". Ou alors il faut que ton collegue configure un "remote" pour acceder à ta branche local.

                  git j'adore, mais j'apprécie aussi la centralisation de SVN (tout sur le même serveur, tu n'as qu'a connaitre le nom de la branche de dev du pote et tu peux travailler dessus).

                  • [^] # Re: plop

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

                    > Mais il faut rajouter une étape, "push" pour envoyer ta branche sur le repo "centrale".

                    Oui, c'est pas un scoop qu'il faut faire un push pour envoyer des commits sur un repo distant. Mais le fait que le commit soit sur une autre branche ou pas ne change pas grand chose.

                    Si tu aimes travailler en centralisé, travaille en centralisé avec Git, il te suffit de faire un push derrière chaque commit (éventuellement un "push --set-upstream").

                  • [^] # Re: plop

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

                    ok, mais comment tu veux avoir des commits locaux (branche ou pas) et ne pas avoir de commande pour dire d'envoyer au serveur ?

                    Et là fin du commentaire ne pose pas de problème, un repo central et tout le monde fait un git clone ce celui-ci, tout le monde push ses branches dessus, donc pas de prob, tu peux le faire avec git.

                    Il y a une commande git pour ça !

                  • [^] # Re: plop

                    Posté par  . Évalué à 2.

                    Personnellement il y a quelques mois j'ai eu à travailler avec git en équipe.
                    Le problème se situait dans le fait de ne pas pouvoir utiliser le protocole git à cause d'administrateurs nazis qui laissent passer que HTTP(S).

                    Et on a bien réussi à travailler avec uniquement des mail générés par git ^^

                    C'est chiant mais ça marche.

                    (Pour info on avait pas la possibilité de modifier la conf' du serveur du dépôt et on utilisait une forge)

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

                    • [^] # Re: plop

                      Posté par  . Évalué à 2.

                      git supporte également le http, le https et le ssh, hein.

                      • [^] # Re: plop

                        Posté par  . Évalué à 2.

                        On avez pas la possibilité de toucher au serveur.

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

                        • [^] # Re: plop

                          Posté par  . Évalué à 4.

                          Le jour ou l'administrateur systeme devient plus une gene qu'une aide il doit degager. Son boulot c'est de faire en sorte que les utilisateurs du systeme puissent bosser comme il faut et dans un environnement securise.

                          Ca sent l'admin qui a installe une fois son syteme, fait si il veut des mises a jour et dors le reste du temps dans son bureau.

                    • [^] # Re: plop

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

                      Le problème se situait dans le fait de ne pas pouvoir utiliser le protocole git à cause d'administrateurs nazis qui laissent passer que HTTP(S).

                      Et incompétents. C'est à cause d'abrutis comme ça qu'un finit par tout faire à travers du HTTP, et que leurs règles débiles ne servent plus à rien puisqu'on les contourne.

                      • [^] # Re: plop

                        Posté par  . Évalué à 1.

                        Souvent dans les grosses boites, ce genre de décision n'est pas pris par l'admin, il faut réunir une tornioles de personne pour décider d'ouvrir tel port, qui évaluera les risques, etc. Ca prend du temps. Beaucoup trop de temps.

                        Résultat tout passe sur HTTP.

                        • [^] # Re: plop

                          Posté par  . Évalué à 2.

                          Au final j'ai qu'une envie me prendre un tout petit serveur et « tuneler » ma connexion.

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

            • [^] # Re: plop

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

              Et moi, je pense qu'il est aussi important de n'avoir que des commit qui compile et sont sensé marcher plus ou moins dans l'historique
              Cela est nécessaire pour des outils comme git-bisect. (très utile)

              Mais je comprends tout à fait l'interêt de commiter tout le temps. Il faudrais pouvoir séparer les commits qui compiles et celle qui sont "travail en cours" ne compiles pas pour que git-bisect puisse quand même fonctionner.

              • [^] # Re: plop

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

                d'où l'intérêt de bosser avec, au choix :
                * des outils tels stgit, Mq ou autre
                * des branches locales (ou pas) perso qu'on merge ensuite

                A lire, on peut croire qu'il ne faut pas qu'il y ait de commit qui ne build pas. En réalité, de moins point de vue, c'est faux. Il ne faut pas de commit qui ne build pas, dans les branches publiques. Dans une branche perso, une branche d'expérimentation, etc ça ne pose pas de problème.

                L'avantage des dcvs est justement de permettre en général d'avoir le meilleur des deux mondes ;)

                • [^] # Re: plop

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

                  > * des outils tels stgit, Mq ou autre

                  "git rebase -i" (y'a une extension Histedit pour Mercurial qui a l'air de faire grosso-modo pareil) est excellent aussi.

                  • [^] # Re: plop

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

                    faudra j'essai, jamais tenté encore
                    Mais la philosophie est différente, dans le cas d'un rebase on modifie l'historique après coup (ou plutôt non pas l'historique mais ce qu'on va envoyer)
                    Avec Mq, stg c'est plus une manière de travailler

                    Au début, j'avais essayé une première fois stg sans trouver à quoi ça servait ni l'intérêt et, pour une raison très merdique (git-svn, pas de merge, que du rebase et du cherry-pick pour moi) je voulais avoir un historique clean lorsque je développe. Donc j'ai retenté stg et là ce fut une révélation !
                    A tel point que je ne me vois pas trop travailler sans un procédé similaire désormais.

                • [^] # Re: plop

                  Posté par  . Évalué à 1.

                  branche perso = le dev fait ce qu'il veut
                  branche de maitnenance, trunk => ca doit compiler, voir meme (celon politique de la boite) ça doit passer un certain nombre de test automatiques.

    • [^] # Re: plop

      Posté par  . Évalué à 1.

      sinon, effectivement, l'idéal sera un repo SVN avec un client git-svn ou hg_svn. Mais avec une interface graphique propre pour faire des pull/push ;)

  • # eclipse + hgtk

    Posté par  . Évalué à 5.

    Perso j'utilise mercurial avec eclipse + hgtk en //.
    Le plugin mercurial de eclipse ayant certaines limites.

    Il faut voir qu'avec ces logiciels de gestions de sources, tu as des fonctionnalités qui n'existe pas dans SVN et qui ne sont pas pas intégré (intégrable?) dans eclipse.
    Par exemple le suivi de fichiers déplacé est mal foutu. Eclipse ne délpace pas il recré puis supprime. du coup pour hg c'est plus le même fichier alors qu'en ligen de commande "hg mv fichier" préserve l'historique.

    Le merge hgtk est excellent, tout graphique et tout et tout.
    Et la gestion de clones aussi.
    Avec une petite équipe, on a vite fait de se sync dans tous les sens et hgtk gardant la liste des dépots en mémoire (avec un nom) tu vas super vite.

    En plus (comme je l'ai dit plus haut) avec hgtk tu as une IHM cohérente avec tortoise si tu travailles aussi sous windows, c'est plutôt pas mal.

    Je connais clearcase, svn et cvs et maintenant que j'utilise hg, je le regrette pas. J'en suis super content.

    J'avais regardé git à un moment mais cela m'était apparu plus compliqué à utilisé que hg et à l'époque (peut-être encore aujourd'hui) inutilisable sous Windows.

    • [^] # Re: eclipse + hgtk

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

      Après avoir essayé mercurial puis git, je trouve mercurial mieux. Même si il y a qqes fonctionnalités qu'on ne retrouve pas dans mercurial par rapport à git, je trouve le projet beaucoup plus simple d'approche :
      - les commandes ont des noms relativement intuitifs
      - il y a moins de commandes
      - la doc et le tutorial sont très bien foutus
      - ca marche nickel sous windows, alors que j'ai eu des problèmes avec git
      - au niveau GUI, ceux que j'ai eu l'occasion d'utiliser pour git me donnait l'impression d'être dans les années 80. Alors que avec TortoiseHg ou hgtk, j'ai plus l'impression d'être au 21e siècle.

      A mon sens, git, même s'il est très puissant souffre d'un côté hardcore developer qu'on ne retrouve pas sous mercurial. Et ça s'en ressent, dans les doc, dans le tutoriaux, dans les GUI, dans les messages d'erreurs, dans l'aide des commandes, etc.

      git a quand même été développé par un mec qui gérait des milliers de patch avec l'email comme seul outil.

      Il est d'ailleurs significatif que des gens qui apprécient git se permettent de t'expliquer que tu as tort de ne pas utiliser la ligne de commande.

      Sinon, hg, c'est quand même un caractère de moins à taper que git, faut surtout pas l'oublier.

      • [^] # Re: eclipse + hgtk

        Posté par  . Évalué à 2.

        merci pour vos deux commentaires constructifs


        Hg, c'est surtout 2 caractères proches sur le clavier ;)

        Je pense effectivement qu'il y a une notion de "culture" dans les projets : un projet qui a une culture de simplicité et de courbe d'apprentissage pas trop dûr engendrera un écosysteme d'outils avec la même approche. Git est hardcore et tous les projets autour le sont, malheureusement j'ai l'impression.

      • [^] # Re: eclipse + hgtk

        Posté par  . Évalué à 5.

        ca marche nickel sous windows, alors que j'ai eu des problèmes avec git

        En meme temps, les mainteneurs de git en ont en gros pas grand chose a foutre de windows. Et le mainteneur du port non-officiel msys est un peu lourdaud sur les bords (meme si on lui en veut pas trop, il fait ca sur son temps libre), avec ses menaces de tout laisser tomber si quelqu'un ose faire un build x64 avec MSVC, ses trips sur les conversions CR+LF <-> CR et son mepris pour les utilisateurs windows (du coup on se demande pourquoi il passe du temps sur ce projet...).

        Du coup, utiliser git sous windows, il faut vraiment aimer souffrir et faire avec des bugs en pagaille et une integration a chier.

        Mercurial + TortoiseHg, avec les plugins SVN & GIT, c'est autre chose niveau integration et facilite d'utilisation.

      • [^] # Re: eclipse + hgtk

        Posté par  . Évalué à 4.

        A mon sens, git, même s'il est très puissant souffre d'un côté hardcore developer qu'on ne retrouve pas sous mercurial. Et ça s'en ressent, dans les doc, dans le tutoriaux, dans les GUI, dans les messages d'erreurs, dans l'aide des commandes, etc.

        Tu veux dire que git est un peu le templeet des systèmes de gestions de versions ?

  • # egit

    Posté par  . Évalué à 3.

    pour egit il y a le merge ca c'est sur. L'historique c'est tout sauf intuitif, il faut passer par clic droit sur un fichier/compare/history et puis une des icones dans la sous fenetre montrant l'historique du fichier pour voir l'historique du depot...

    Actuellement ce qui manque le plus a mon avis c'est la gestion des depots utilisant gitosis (ou equivalent). En gros egit demande le mot de passe alors qu'il y a la cle ssh et donc tu ne peux pas "fetcher" et "pusher" sur ce genre de depot de facon graphique. Mais si quelqu'un connais la methode je suis preneur.

    • [^] # Re: egit

      Posté par  . Évalué à 1.

      oups j'oubliais le lien vers la doc de egit avec copie d'ecran

      http://wiki.eclipse.org/EGit/User_Guide

      mais elle me semble un peu obsolete avec Helios (a verifier).

      • [^] # Re: egit

        Posté par  . Évalué à 1.

        pas trouvé de merge dans egit 0.8 que j'ai sous helios. Manque beaucoup d'autre chose, comme l'historique sur le dossier (je l'avait à un moment, puis plus rien).

        • [^] # Re: egit

          Posté par  . Évalué à 1.

          pour le merge: clic droit/team/merge
          pour l'historique des dossiers en effet je ne vois pas et cela m'etonne aussi car je l'avais vu un temps. Enfin je me suis apercu que je m'en sors plus vite et mieux avec la ligne de commande donc bon c'est juste par curiosite que je teste ca de temps en temps.

  • # Première ligne, premier troll

    Posté par  . Évalué à 10.

    "Je travaille beaucoup avec SVN et CVS sous linux, essentiellement avec eclipse. J'aimerais beaucoup passer à un vrai gestionnaire de version"

    Bonne plaisanterie ! Que GIT soit meilleur que SVN, pourquoi pas. Que SVN soit un faux gestionnaire de version, merci l'intégrisme.

    • [^] # Re: Première ligne, premier troll

      Posté par  . Évalué à 0.

      il voulait peut etre dire "veritable gestionnaire de version distribue"?

    • [^] # Re: Première ligne, premier troll

      Posté par  . Évalué à 9.

      En effet seule sa gestion des branches est fausse.

      DLFP >> PCInpact > Numerama >> LinuxFr.org

    • [^] # Re: Première ligne, premier troll

      Posté par  . Évalué à 8.

      CVS n'est qu'un gestion de version de fichier, pas de révision de l'arbre de code.
      SVN est un gestionnaire de version de dossier, pas de résition de l'arbre de code dans le sens le plus pûr.

      SVN est presque idéal néanmoins:
      - renomme un fichier et tu es mort lors des merges (rien que ça ça décridibilise la notion de gestionnaire de code)
      - les merges demandent trop d'effort (je suis faignant). Je dois faire attention de ne pas oublier un commit lors d'un merge, alors que ce que je veux c'est "branche A => Branche B". Merci au revoir. C'est possible de le faire, l'ancètre commun est facile à trouver. Git et Hg le font très bien. Collabnet et son merge utility permet de simplifier le truc, néanmoins ce n'est pas idéale.

      Maintenir une branche de dev et une branche de production doit être le plus simple possible, avec une vue claire de ce qui est appliquée ou pas. Et surtout une vue efficace des merges. Sur les projets SVN, j'utilise le plugin revision history de trac, qui est pas mal (mais il manque des svn:info.... pourquoi il y a des "extensions" (loi de murphy, qui dit extention dit forcément "manquante") comme ça, alors que ça devrait être obligatoire.

  • # et pourquoi pas bazar ?

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

    ça réponds à tes attentes, et il y a des GUIs très biens

  • # Magit

    Posté par  . Évalué à 1.

    Très bon, Magit.

    Mais du coup, faut passer à Emacs...

  • # Une bonne GUI pour git et pour mercurial:

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

    konsole

  • # Tout dépends de ce que tu cherches

    Posté par  . Évalué à 6.

    Au niveau des outils, mercurial et git possédent des interfaces graphiques (tortoise-hg, gitg, etc ...) et des greffons d'intégrations à différents environnements de développement (emacs, eclipse, netbeans, Qt Creator, etc ...). Le fonctionnement interne de mercurial est similaire à git, la gestion des branches est tout aussi aisée.

    Pour bien connaitre les deux, j'estime que la principale différence est au niveau de l'interface utilisateur (en général).
    Mercurial a été conçu pour être simple et extensible, git pour être le plus souple et rapide possible. Mercurial offre une interface plus simple à appréhender (moins de commande, moins d'options obscures) et la documentation en ligne est extrêmement bien faite. La plupart des commandes reprennent la sémantique de leur homologue svn ce qui facilite le passage depuis ce VCS.
    Mercurial offre autant de possibilité que Git, la différence étant que les commandes non-essentielles sont fournis à travers des extensions (stash --> record, cherry-picking --> transplant etc ..), on n'utilise uniquement ce dont on a besoin. Je le précise parce qu'on m'a déjà posé la question, les extensions n'influent pas sur le format de dépôt et donc aucun problème d'intéropérabilité. La plupart des extensions sont inclus dans la distribution standard (et même supporté par les outils externes).
    Pour une personne qui n'a jamais manipulé un DVCS (voire un VCS), c'est probablement un meilleur choix que Git qui offre une interface plus brouillon et des choix par défaut bizarres (même si ça c'est beaucoup amélioré depuis)


    Git expose littéralement ses entrailles, ce qui demande quelques notions du fonctionnement interne de Git. Beaucoup de commandes, de notions nouvelles (staging area, stash, etc ...), contrairement à mercurial, il faut régulièrement passer le balai (git count-objects est ton ami) pour virer les merdes qui s'accumulent sous peine de perdre en perfs, ce qui rends la courbe d'apprentissage plus longue qu'avec mercurial mais il est indéniablement plus souple et très rapide.
    C'est clairement un DVCS fait par et pour les power users.


    Mercurial et Git sont tout à fait matures dans ton cadre d'utilisation, ils existent des plugins eclipse pour les deux DVCS (celui pour Mercurial est même plus mature qu'EGit), les deux offrent tout autant de possibilités. Si tu cherches un DVCS idiot-proof, je te recommanderais mercurial, si tu veux la puissance à moindre frais git

Suivre le flux des commentaires

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