Journal Mercurial, un petit cookbook en français.

Posté par .
Tags : aucun
0
7
nov.
2007
Au cours de mon stage cet été dans un laboratoire de réalité virtuelle de l'université Marne-la-Vallée/Paris-Est [1] j'ai passé le toolkit de RV local sous le fantastique système de gestion de version distribué Mercurial [2].
La documentation francophone étant rare, et la documentation anglophone pas forcement pratique, j'ai écrit un petit cookbook regroupant les manipulations de tous les jours.
Je le met à disposition en pdf [3] et en latex [4] sous licence WTFPL [5].
Si ça peut aider les débutants ou convaincre d'autres gens que CVS et Subversion ne sont pas la solution ultime dans beaucoup de cas ça sera pas mal.
N'hésitez pas à faire remonter remarques, fautes d'orthographe, incompréhensions et autres erreurs.

[1] http://www.univ-mlv.fr/
[2] http://fr.wikipedia.org/wiki/Mercurial
[3] http://zaeron.com/files/MercurialCookbookFr.pdf
[4] http://zaeron.com/files/MercurialCookbookFr.tex
[5] http://sam.zoy.org/wtfpl/
  • # Tres interessant

    Posté par . Évalué à 4.

    et complet, merci bien !

    Je me demandais comment ca marchait en decentralise (je connais un peu svn) c'est plus clair.

    Question malgre tout : apres quelque semaines, le store (si je comprends bien la partie 'historique' du projet) n'est pas tres (trop ?) volumineuse ?
    • [^] # Re: Tres interessant

      Posté par . Évalué à 3.

      Pour exemple, la lib sur lequel je l'utilise occupe 12mo, dont 3mo de store, après deux mois d'utilisations et une centaine de changeset.
      Si on prend comme exemple dwm [1] le repertoire de developpement occupe 1.3mo dont 1.2mo de store après deux ans d'utilisation et environ 1100 changesets.
      Le store a donc une taille incompressible raisonnable et qui n'augmente pas linéairement en fonction de la taille des sources, donc un projet de 150mo aura un store probablement inférieur à 10mo. C'est une des raisons pour laquelle Mercurial est utilisé sur des gros projets.

      D'ailleurs une bonne manière de tester Mercurial est d'experimenter sur le repository dwm :
      hg clone http://www.suckless.org/hg.rc/dwm

      [1] http://www.suckless.org/wiki/dwm
      • [^] # Re: Tres interessant

        Posté par . Évalué à 2.

        A titre de comparaison/information :

        git sur les sources du noyau (arbre de Linus) du 2.6.12-rc2 au 2.6.24-rc2 (73237 commits) : 178Mo
        un simple 2.6.24-rc2 fait 304Mo décompressé...
  • # Errata 8.3.1

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

    Hello,

    Ton guide est de bonne qualité et propre. Merci :-)

    Une faute est présente dans le paragraphe 8.3.1 :
    « Par défaut la commande pull interdit la création de nouvelles head dans le repository distant (...) »

    « pull » serait plutôt à remplacer par « push ».
  • # Autre lien

    Posté par . Évalué à 7.

    D'ailleurs le hgbook étant sous licence libre, une traduction pourrait se faire non ? (et serait peut etre meme publiable).

    http://hgbook.red-bean.com/
  • # Petit retour

    Posté par . Évalué à 4.

    Comme toi j'apprécie beaucoup Mercurial.

    Je trouve la documentation anglophone excellente, mais je te félicite pour ton document.

    J'ai une toute petite remarque : tu ne parles pas des dépots en static-http.
    C'est quelque chose qui n'est pas mis en avant par Mercurial, je le reconnais, mais qui est très pratique pour toute personne voulant distribuer ses projets au monde entier sans disposer d'un hébergement qui supporte les cgi.
    Quelques lignes dessus serait un plus à ton document, à mon avis :-)

    Je trouve que la partie sur "maintenir 2 versions d'un projet" est confuse.
    Tu mélanges versions et branches et, à mon avis, tu compliques les choses plus qu'il ne faudrait.


    Sinon le reste me parrait pas mal du tout.
    Encore bravo pour cette initiative.
    ++
    Chicha
  • # Problème de pdf ?

    Posté par . Évalué à 2.

    ça n'a pas vraiment de lien et c'est plutot hors sujet, mais chez moi le pdf se lit trés bien avec xpdf mais trés mal avec evince ... Alors que evince fonctionne bien habituellement ...

    Je ne sais pas du tout a quoi c'est dû ... Si vous avez une idée ?
    • [^] # Re: Problème de pdf ?

      Posté par . Évalué à 2.

      Etrange, l'utilisation de
      \usepackage[T1]{fontenc}
      bruite le rendu dans evince.
      C'est corrigé, mais je vois pas d'ou peut venir ce bug.
      • [^] # Re: Problème de pdf ?

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

        Probablement le fait qu'en T1, les polices computer modern ne sont pas incluses dans le pdf*, or celles-ci ne sont pas distribuées avec tous les lecteurs de pdf.

        *: à moins de forcer l'inclusion par exemple en incluant le package aeguill qui ajoute les guillemets français.
        • [^] # Re: Problème de pdf ?

          Posté par . Évalué à 2.

          Effectivement avec le package cm-super ça marche tout de suite mieux, par contre en lisant un peu de doc la dessus c'est le package lmodern qui est préconisé.
  • # Merci pour les retours

    Posté par . Évalué à 3.

    Et donc je viens d'effectuer les corrections, ajouts et modifications suggérées.

    Effectivement la dernière partie n'était pas claire, c'est surtout pour répondre aux besoins du labo, qui a besoin de disposer d'une version avec du code privé en plus du code public. J'ai reformulé cette partie.
    • [^] # Re: Merci pour les retours

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

      Très bonne initiative.
      <ma_vie>Après plusieurs expériementations, j'envisage de proposer Mercurial dans ma boite, car plus abordable que Git.</ma_vie>

      Afin de faire vivre ton oeuvre, il me semble que tu pourrais :
      - soit ouvrir un dépot mercurial (peut-être sur le site officiel),
      - soit (si tu as un peu de temps) le convertir et le déposer sur http://fr.wikibooks.org/ (il n'y a rien actuellement concernant Mercurial)
      Dans le second cas, je suis sûr que tu peux même obtenir un peu d'aide si tu amorce le truc.

Suivre le flux des commentaires

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