• # my 2 cts

    Posté par . En réponse au message Mercurial bis. É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