(Traduction du texte original en anglais : Repository)
Dépôt (ou référentiel)
(pour une courte introduction des concepts de base de Mercurial, voir UnderstandingMercurial)
Pour être précis, le terme de dépôt fait référence à un dossier nommé .hg (point hg) dans le dossier racine du dépôt. Le dossier racine du dépôt est le dossier parent du dossier .hg. Mercurial sauvegarde ses données de structure internes – ses métadonnées – dans ce dossier .hg.
Tous les fichiers et dossiers qui coexistent avec le dossier .hg à la racine du dépôt sont dits demeurant dans le dossier de travail.
Un moyen facile de ce souvenir de cette différence est de réaliser que le dépôt contient un historique de votre projet, tandis que le dossier de travail contient un "instantané" de votre projet à un point donné de cet historique.
Les dépôts Mercurial locaux sont adressés en spécifiant le chemin vers le dépôt racine (l'option globale -R de la commande).
Parfois les utilisateurs de Mercurial et les développeurs utilisent également le terme de "dépôt" pour faire référence à la racine du dépôt. Mais s'il faut être rigoureux, le dossier .hg est le "vrai" dépôt.
Contents
1. Création
Les dépôts peuvent être clonés par hg clone, qui créé une copie d'un dépôt existant. Si possible, mercurial utilise des hardlinks pour économiser l'espace disque et accélérer le clonage (voir HardlinkedClones).
Un dossier existant, déjà rempli mais pas encore versionné peut être transformé en dépôt par hg init, ce qui créer et initialise le sous-dossier .hg.
2. Versionner les fichiers
Un fichier dans le dossier de travail pour être versionné par Mercurial doit être ajouté avec hg add. Les modifications locales des fichiers versionnés dans le dossier de travail peuvent être validés avec hg commit, ce qui ajoute un nouveau changeset au dépôt en l'enregistrant dans le dossier .hg.
Le dossier de travail peut être restauré avec hg update vers un état précédemment validé en spécifiant le changeset visé par son changeset ID (voir Update). Utilisez hg parents pour voir la révision extraite courante (voir Parent).
Le dernier commit d'un dépôt peut être annulé avec hg rollback (voir Rollback).
3. Transférer des changesets
Les changesets peuvent être transférés d'un dépôt à un autre avec hg pull, hg push, hg export and hg import (voir Pull, Push, Export, Import, CommunicatingChanges).
4. Vérifier l'intégrité
L'intégrité interne d'un dépôt (le contenu de .hg) peut être vérifiée avec hg verify.
5. Structure
Le dossier .hg d'un dépôt contient (liste non-exhaustive) :
Le manifest — Fichiers .hg/store/00manifest.i et .hg/store/00manifest.d
Décrit les contenus des fichiers du dépôt à un ID de changeset particulier. Stocké au format revlog.
Le changelog — Fichiers .hg/store/00changelog.i and .hg/store/00changelog.d
- Contient tous les changesets stockés au format revlog.
Un revlog par fichier versionné — Fichiers .hg/store/data/<chemin encodé>.i and .hg/store/data/<chemin encodé>.d
<chemin encodé> est le chemin du fichier versionné dans le dossier de travail, encodé selon le CaseFoldingPlan.
L'état du dossier — Fichier .hg/dirstate
- Versionne diverses informations à propos du dossier de travail.
Les fichiers de pré-requis — Fichier .hg/requires
- Spécifie les aptitudes exigées par un client pour l'accès au dépôt.
Notez que pour de petits revlogs, le fichier de données revlog (*.d) peut être absent, parce que son contenu peu être incorporé dans le fichier d'index correspondant (*.i) (voir également RevlogNG).
6. Sauvegarde
La sauvegarde d'un dépôt peut être réalisée en utilisant push/pull/clone vers un dépôt de sauvegarde. Un dépôt qui n'est pas modifié activement (par d'autre processus concurrent tournant sur la machine) peut être sauvegardé en sauvegardant le dossier du dépôt par les moyens normaux d'archivage de dossier/fichier (comme tar, zip, etc.). Le dossier .hg est insensible à la casse, ce qui signifie qu'il peut par exemple être copié sur un système de fichier FAT (voir aussi BackUp, CaseFoldingPlan).