Forum Linux.général Mercurial bis

Posté par  (site web personnel) .
Étiquettes : aucune
1
17
août
2011

Bonjours,

Je suis passé à Mercurial suite à ma précédente question sur ce forum. J'avoue que j'aime bien le fonctionnement de Mercurial et j'en suis pour l'instant très content (même si pour certaine chose je ne suis pas encore habitué, j'oublie parfois de faire un push pour récupérer mes dev sur une autre machine).

Je me posais plusieurs questions :

  • Êtes-vous plutôt merge ou rebase ? Pour l'instant je fait plutôt du rebase car ainsi l'arbre est plat mais peut-être est-ce plus intéressant de faire merge ?
  • Êtes-vous plutôt branche nommé, clone, multi-head ? Pour l'instant je pense que je ferai des branches nommé pour chaque sortie de nouvelle version, mais je suis plutôt pour la méthode clone quand je dois faire une branche de développement.

Et enfin la question la plus importante ! Je connais bitbucket qui est utilisé par beaucoup de personne. Je vois deux avantages à bitbucket :

  • La création de fork (le clone est fait par la plateforme qui le met à disposition du publique)
  • La possibilité de faire des pull-request (utile quand les fork doivent être remergé).

De mon coté, je suis pour le contrôle de mes sources et l'auto-hébergement. J'ai mis en place un serveur pour mes projets (http://hg.shadoware.org) et je me demandais s'il existait des projets qui me permettrait de

  • facilement cloner un de mes projets (pour en faire une branche de dev) à partir d'une interface web, et de le mettre tout de suite à disposition sur mon serveur, comme le fait bitbucket (ou plus simplement). Actuellement je peux cloner le projet, mais la branche de dev se trouve alors sur mon poste de travail et ce n'est donc pas aussi pratique.
  • faire du pull-request, voir plutôt que des personnes puisse facilement faire un pull-request sans passer par bitbucket, soit en clonant sur mon serveur, soit à l'aide d'une interface, bref je suis ouvert.

En claire (et sans décodeur), je souhaite savoir s'il existe une alternative libre (même simplifié) à la plateforme bitbucket.

Merci à tous et bonne journée

  • # Re: Mercurial bis

    Posté par  . Évalué à 1.

    Je suis passé à Mercurial

    Félicitations ! ;-)

    Êtes-vous plutôt merge ou rebase ?

    rebase pour une même branche de développement, et transplant pour back-porter des correctifs. En fait, j'utilise ultra-rarement le rebase, car j'utilise les MQs ; l'équivalent d'un rebase, c'est : hg qpop -a && hg pull --update && hg qpush -a

    Êtes-vous plutôt branche nommé, clone, multi-head ?

    J'utilise des branches nommées pour les branches de release (eg. 1.12 pour toute la série des 1.12.x) et une seule branche pour le développement (default), pas de multi-head (le multi-head est en contradiction avec le rebase), et je développe dans plusieurs clones, avec une ou plusieurs MQs par clone.

    faire du pull-request

    J'ai jamais essayé bitbucket, je suis absolument orienté auto-hébergement. Il n'y a pas de commande Mercurial qui soit équivalente à git request-pull. Tiens, du coup, je vais peut-être regarder à implémenter ça un de ces quatres...

    Sinon, j'ai quelques petits scripts qui peuvent t'être utiles :
    http://ymorin.is-a-geek.org/hg/mercurial/hgutils/

    Hop,
    Moi.

    PS. Moi, les clones, je trouve ça rigolo ! :-]

  • # my 2 cts

    Posté par  . Évalué à 2.

    1. rebase, ça permet d'avoir un historique linéaire, plus lisible (pas de message automatique de merge qui pollue les logs). En règle générale, on privilègie le rebase pour travailler sur une même branche ou les branches à durée de vie courte (par exemple, développer une fonctionnalité sans péter sa branche, faire un POC etc rapide), le merge pour fusionner deux branches. Les mercurial queues sont aussi une alternative aux branches à durée de vie courte. Transplant pour récupérer des bug fixes à partir d'autres branches.
    2. bookmarks (multi-head avec une étiquette) qui est plus ou moins l'équivalent des branches git. Bookmarks a été intégré au coeur de mercurial depuis la version 1.8 (auparavant c'était une extension fournie dans la distribution officielle) Pour les versions, je te conseille de les tagger et de créer les branches au fur et à mesure (ça ne sert à rien une branche si derrière, tu bosses jamais dessus)
    3. l'intérêt de bitbucket & cie, c'est de partager ton code: t'as un bug tracker, un wiki, une exposition, un dépôt central pour pas cher
    4. oui, RhodeCode, mais c'est pas aussi bien chiadé que Bitbucket http://rhodecode.org/ Perso, j'ai un compte bitbucket payant pour mes projets freelance et j'utilise mercurial-server pour les autres (un gitolite-like pour ceux qui connaissent) http://www.lshift.net/mercurial-server.html

    • [^] # Re: my 2 cts

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

      Je viens de tester Rhodecode qui correspond a peut prés à ce que je cherchais. Merci. Par contre j'ai du le désinstaller car il m'a installer une version python de mercurial qui ne correspond pas à celle de mon serveur, et qui donc rentrer en conflit avec ma version...

      Pourquoi Python n'utilise-t-il pas le gestionnaire de paquet de la distribution !!!

      Il faudra que je regarde à l'installer autrement (peut-être à l'aide de virtualenv si cela permet de ne pas tout casser).

      Sinon merci quand même.

      Quel est l'avantage des bookmark par rapport au branche ?

      • [^] # Re: my 2 cts

        Posté par  . Évalué à 3.

        L'inconvénient des branches "nommées" dans mercurial sont que le nom est inscrit dans les metadata des changesets qu'on se traine éternellement ce qui n'est pas pratique dans l'optique des branches à durée de vie très courtes.
        C'est la principale différence entre les branches git et les branches mercurial, les commits git ne conservent aucune information de branches.

        En revanche, mercurial a toujours supportés les branches type git via les "heads", sauf que les heads n'avaient pas de nom à l'origine et du coup, c'est très chiant pour changer de head. L'extension bookmark (désormais intégré dans le coeur de mercurial) a permis d'ajouter une étiquette à un head et d'avoir un équivalent total aux branches git.

        C'est très pratique de pouvoir créer une branche pour expérimenter sans se soucier à priori de savoir si on réintegrera ou non nos expérimentations (et éventuellement se trainer des metadata inutiles ad vitam eternam - surtout quand on donne des noms très cons aux branches jetables -).
        Dans le même ordre de considération, les mercurial queues permettent d'avoir une souplesse similaire (voire supérieure) mais ça n'est pas forcément du goût de tout le monde de gérer des patchs queues.

Suivre le flux des commentaires

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