FrenchUnderstandingMercurial

(Traduction du texte original en anglais : UnderstandingMercurial)

Le modèle de développement décentralisé de Mercurial peut être confus pour les nouveaux utilisateurs. Cette page tente d'illustrer certains des principes fondamentaux. Reportez vous au Tutorial pour des instructions étape par étape.

(Traductions: English, Brazilian Portuguese, Chinese, French, German, Italian, Japanese, Korean, Russian, Spanish, Thai )

Contenu d'un dépot

Les dépots Mercurial contiennent un répertoire de travail couplé avec un entrepôt :

L'entrepôt contient l'historique complet du projet. A la différence des SCMs classiques, où il n'y a qu'une copie centrale de cet l'historique, chaque répertoire de travail est associé avec une copie privée de cet historique. Ceci permet au développement d'évoluer parallèlement.

Le répertoire de travail contient une copie des fichiers du projet à un certain point du temps (ex : rev. 2), prêts à être édités. Parce que les tags et les fichiers ignorés sont enregistrés dans une révision, ils sont aussi inclus.

Changements commités

Lorsque vous faites un commit, l'état du répertoire de travail relatif à ses parents est enregistré comme un nouveau changeset (aussi appelé une nouvelle "revision") :

Notez ici que la révision 4 est une branche de la révision 2, qui est la révision dans le répertoire de travail. Maintenant, la révision 4 est le parent du répertoire de travail.

Révisions, Changesets, Head et Tip

Mercurial groupe les changements relatifs à de multiples fichiers dans d'uniques changesets atomiques qui forment les révisions du projet global. Chacun prend un numéro de révision séquenciel. Puisque Mercurial autorise des développement distribués et parallèles, ces numéros de révisions peuvent être différents suivant les utilisateurs. Ainsi, Mercurial assigne à chaque révision un ID de changeset global. Ces ID de changesets sont des nombre hexadécimaux de 40 digits de long, mais peut être abrégés à n'importe quel préfixe non ambigu comme "e38487"

Des branches et merges peuvent appraître dans en tout point de l'historique des révisions. Chaque branche non encore "mergée" crée un nouvel head de l'historique. Ici, les révisions 5 et 6 sont des heads. Mercurial considère la révision 6 comme étant le tip du dépôt, c'est à dire le head avec le plus grand numéro de révision. La révision 4 est un changeset de merge (merge changeset) puisqu'il possède deux changesets parents (révisions 2 et 3).

Cloner, faire des changements, Merger, envoyer (pull) et mettre à jour (upgrade)

Commençons avec un utilisateur Alice qui possède un dépôt qui ressemble à ceci :

Bob clone ce dépôt, et récupère ainsi une copie locale, complète et indépendante de l'entrepôt d'Alice ainsi qu'une vue propre de la révision "tip" d dans son répertoire de travail.

Bob peut maintenant travailler indépendamment d'Alice. Il commit deux changements e et f :

Alice apporte ensuite un changement g en parallèle à son propre dépôt, ce qui conduit à des divergences entre les entrepôt d'Alice et Bob, créant ainsi une branche :

Bob récupère (pull) ensuite le dépôt d'Alice pour synchroniser. Ceci copie tous les changements d'Alice dans l'entrepôt de Bob (ici, il n'y a qu'un seul changement : g). Notez que le répertoire de travail de Bob n'est pas changé par la récupération :

Comme le g d'Alice est le head le plus récent dans le dépôt de Bob, g est maintenant le tip.

Bob fait ensuite un merge pour combiner les derniers changements sur lesquels il était en train de travailler (f) avec le tip dans son dépôt. Maintenant, son répertoire de travail possède deux révisions parentes (f et g) :

Après avoir examiné le résultat du merge dans son répertoire de travail et avoir fait en sorte que ce merge soit parfait, Bob commit le résultat et finit avec un nouveau changeset de merge (merge changeset) h dans son entrepôt :

Maintenant, si Alice récupère (pull) depuis Bob, elle obtiendra les changement e, f et h de Bob dans son propre entrepôt :

Notez que le répertoire de travail d'Alice n'a pas été changé par la récupération. Elle doit faire un update pour synchroniser son répertoire de travail avec le changeset de merge h. Ceci change le changeset parent de s on répertoire de travail pour le changet h et met à jour les fichiers dans son répertoire de travail à la révision h.

Maintenant, Alice et Bob sont totalement synchronisés à nouveau.

Un système décentralisé

Mercurial est un système totalement décentralisé et ne possède donc pas de notion interne de dépôt central. Ainsi, les utilisateurs ont toute la liberté de créer leur propre topologie pour partager les changements (cf. communiquer les changements)) :

A la différence d'un gestionnaire de version centralisé dans lequel l'expérimentation peut être désastreuse, dans un DSCM comme Mercurial, vous avez juste à cloner et expérimenter. Si vous aimez le résultat, envoyez (push) le en retour, sinon, supprimez le dépôt cloné et testez quelque chose d'autre.

Ce que Mercurial ne peut pas faire

Beaucoup d'utilisateurs SVN/CVS espèrent héberger tous leurs projets ensemble dans un seul dépôt. Mais Mercurial n'a pas été conçu dans cet esprit. En effet, vous ne pouvez pas récupérer juste un répertoire dans un dépôt. Vous devriez donc essayer d'organiser vos projets autrement.

Si vous avez quand même absolument besoin d'héberger plusieurs projets dans une sorte de méta-dépôt, vous pouvez essayer la fonctionnalité des sous-dépôts qui ont été introduits dans Mercurial 1.3 ou l'ancienne extension Forest

Pour des instructions par l'exemple sur comment utiliser Mercurial, reportez vous au Tutorial

CategoryFrench