reposurgeon - En ligne dans le Cloud

PROGRAMME:

Nom

rechirurgien - opérations chirurgicales sur entrepôts

SYNOPSIS

repurger [commander...]

DESCRIPTION

À notre humble avis, repurger est de permettre des opérations risquées que les VCS (version-control
systèmes) ne veulent pas vous laisser faire, comme (a) éditer les commentaires et métadonnées passés, (b)
l'excision des commits, (c) la fusion et la division des commits, (d) la suppression des fichiers et des sous-arbres
à partir de l'historique des pensions, (e) fusionner ou greffer deux ou plusieurs pensions, et (f) couper une pension dans
deux en coupant un lien parent-enfant, en préservant la structure de branche des deux dépôts enfants.

La motivation originelle de repurger était de nettoyer les artefacts créés par le référentiel
reconversions. Il était prévu que l'outil aurait également des applications lorsque le code doit
être supprimés des référentiels pour des raisons juridiques ou politiques.

Garder repurger simple et flexible, il ne fait normalement pas son propre référentiel
lire et écrire. Au lieu de cela, il repose sur la capacité d'analyser et d'émettre la commande
flux créés par git-fast-export et lus par git-fast-import. Cela signifie qu'il peut être
utilisé sur tout système de contrôle de version doté à la fois d'utilitaires d'exportation et d'importation rapides.
Le format de flux git-import définit également implicitement un langage commun de primitives
opérations pour repurger parler.

Systèmes entièrement pris en charge (ceux pour lesquels repurger peut à la fois lire et écrire des référentiels)
inclure git, hg, bzr, svn, darcs, RCS et SRC. Pour une liste complète, avec dépendances et
notes techniques, tapez préfère à la repurger rapide.

L'écriture sur les systèmes orientés fichiers RCS et SRC se fait via rcs-importation rapide(1) et a
de sérieuses limitations car ces systèmes ne peuvent pas représenter toutes les métadonnées d'un
flux git-fast-export. Consultez la documentation de cet outil pour plus de détails et
solutions de contournement.

L'écriture de référentiels Subversion a également des limitations importantes, discutées dans le
section sur l'utilisation de Subversion.

Les fichiers du référentiel de fossiles peuvent être lus à l'aide du --format=fossile choix du lire
commande et écrite avec le --format=fossile choix du écrire. Ignorer les modèles sont
pas traduit dans les deux sens.

CVS est pris en charge en lecture seule, pas en écriture. Pour CVS, repurger doit être exécuté à partir d'un
répertoire du référentiel.

Pour obtenir des conseils sur la pragmatique de la conversion de référentiel, consultez le DVCS Migration COMMENT[1].

SECURITE MISES EN GARDE

repurger est un outil assez tranchant pour vous couper. Il prend soin de ne jamais écrire un
référentiel dans un état réellement incohérent, et se terminera avec un message d'erreur
plutôt que de procéder lorsque ses structures de données internes sont confuses. Cependant, il y a
beaucoup de choses que vous pouvez faire avec - comme modifier les horodatages des commits stockés pour qu'ils ne
correspondent plus à la séquence de validation - qui sont susceptibles de causer des ravages une fois que vous avez terminé.
Procédez avec prudence et vérifiez votre travail.

Notez également que, si votre DVCS fait la chose habituelle de transformer les identifiants de validation en un
hachage du contenu et des liens parents, édition d'un référentiel accessible au public avec cet outil
serait une mauvaise idée. Toutes les opérations chirurgicales en repurger va modifier le hachage
chaînes, ce qui signifie que d'autres deviendront incapables de tirer ou de pousser vers le repo.

Veuillez également consulter les notes sur les problèmes spécifiques au système dans la section intitulée « LIMITATIONS
ET GARANTIES ».

FONCTIONNEMENT

Le programme peut être exécuté dans l'un des deux modes, soit en tant qu'interpréteur de commandes interactif
soit en batch pour exécuter des commandes données en arguments sur le repurger invocation
ligne. Les seules différences entre ces modes sont (1) le mode interactif commence par
en activant l'option 'verbose 1', (2) en mode batch toutes les erreurs (y compris normalement
erreurs récupérables dans la syntaxe du jeu de sélection) sont fatales, et (3) chaque argument de ligne de commande
commençant par "--", cela a été supprimé (ce qui signifie en particulier que --help et
--version fonctionnera comme prévu). De plus, en mode interactif, Ctrl-P et Ctrl-N seront
disponible pour faire défiler l'historique de vos commandes et l'achèvement des onglets des mots-clés de commande est
disponible.

Un flux git-fast-import consiste en une séquence de commandes qui doivent être exécutées dans le
séquence spécifiée pour construire le référentiel ; pour éviter toute confusion avec repurger commandes nous allons
référez-vous aux commandes de flux comme l'évènementiel dans cette documentation. Ces événements sont implicitement
numérotés à partir de 1. La plupart des commandes nécessitent de spécifier une sélection de séquence d'événements
les nombres donc repurger saura quels événements modifier ou supprimer.

Pour tous les détails sur les types d'événements et la sémantique, consultez le git-fast-importation(1) page de manuel ;
le reste de ce paragraphe est un début rapide pour les impatients. La plupart des événements d'un flux sont
commits décrire les états de révision du référentiel ; ceux-ci se regroupent sous un même
modifier un ou plusieurs commentaires fichiers (opérations sur les fichiers), qui pointent généralement vers gouttes qui
sont des états de révision de fichiers individuels. Un fileop peut aussi être une opération de suppression
indiquant qu'un fichier spécifié précédemment existant a été supprimé dans le cadre de la version
s'engager; il existe quelques autres types de fichiers spéciaux de moindre importance.

Commandes à repurger consistent en un mot-clé de commande, parfois précédé d'une sélection
set, parfois suivi d'arguments séparés par des espaces. Il est souvent possible d'omettre
l'argument de l'ensemble de sélection et qu'il soit par défaut quelque chose de raisonnable.

Voici quelques exemples motivants. Les commandes seront expliquées plus en détail après la
description de la syntaxe de sélection.

:15 modifier ;; éditer l'objet associé à la marque :15

Éditer ;; modifier tous les objets modifiables

liste 29..71 ;; liste sommaire index des événements 29..71

236..$ liste ;; Liste des événements du 236 au dernier

<#523> inspecter ;; Recherchez le commit #523 ; ils sont numérotés
;; 1-origine depuis le début du référentiel.

<2317> inspecter ;; Recherchez une balise avec le nom 2317, un commit de conseil
;; d'une branche nommée 2317, ou d'un commit avec un identifiant hérité
;; 2317. Inspectez ce qui est trouvé. Un nombre simple est
;; probablement un identifiant hérité hérité d'un Subversion
;; numéro de révision.

/regression/ list ;; lister tous les commits et tags avec des commentaires ou
;; les en-têtes de committer ou les en-têtes d'auteur contenant
;; la chaîne "régression"

1..:97 & =T supprimer ;; supprimer les balises de l'événement 1 à la marque 97

[Makefile] inspecter ;; Inspectez tous les commits avec une opération de fichier touchant Makefile
;; et tous les blobs mentionnés dans un fichier op
;; toucher Makefile.

:46 pourboire ;; Affiche l'astuce de la branche qui possède commit :46.

@dsc(:55) liste ;; Afficher tous les commits avec le traçage d'ascendance jusqu'à :55

@min([.gitignore]) supprimer .gitignore supprimer
;; Supprimez le premier fichier .gitignore dans le référentiel.

SÉLECTION SYNTAXE
La syntaxe de spécification de l'ensemble de sélection est un minilangage orienté expression. Le plus
terme de base dans cette langue est un emplacement. Les types d'emplacements primitifs suivants sont
prise en charge:

numéros d'événement
Un littéral numérique simple est interprété comme un numéro de séquence d'événement à 1 origine.

marques
Un littéral numérique précédé de deux points est interprété comme une marque ; voir le flux d'importation
documentation de format pour l'explication de la sémantique des marques.

noms de balises et de branches
Le nom de base d'une branche (y compris les branches dans l'espace de noms refs/tags) fait référence à son
astuce commit. Le nom d'une balise équivaut à sa marque (celle de la balise elle-même, non
le commit auquel il fait référence). Les emplacements des balises et des branches sont entourés de < > (angle
crochets) pour les distinguer des mots-clés de commande.

identifiants hérités
Si le contenu des crochets de nom (< >) ne correspond pas à une balise ou à un nom de branche, le
l'interpréteur recherche ensuite les identifiants hérités des commits. Ceci est particulièrement utile lorsque vous
avoir importé un dump Subversion ; cela signifie que les engagements qui en découlent peuvent être référés
par leurs numéros de révision Subversion correspondants.

numéros de validation
Le littéral numérique entre crochets (< >) précédé de # est interprété comme une origine 1
numéro de séquence de validation.

$
Fait référence au dernier événement.

Ceux-ci peuvent être regroupés en ensembles des manières suivantes :

gammes
Une plage est constituée de deux emplacements séparés par "..", et est l'ensemble d'événements commençant au
emplacement de gauche et se terminant à l'emplacement de droite (inclus).

listes
Les listes d'emplacements et de plages séparées par des virgules sont acceptées, avec la signification évidente.

Il existe d'autres façons de construire des ensembles d'événements :

ensembles de visibilité
Un ensemble de visibilité est une expression spécifiant un ensemble de types d'événements. Il consistera en
un signe égal en tête, suivi de lettres types. Ce sont les lettres types :

?? ??
│B │ blobs │ La plupart des sélections par défaut │
│ │ │ les ensembles excluent les blobs ; ils
│ │ │ doit être manipulé │
│ │ │ à travers les commits ils │
│ │ │ sont attachés à. ??
?? ??
C │ commet │ │
?? ??
│D │ commits all-delete │ Ce sont des artefacts │
│ │ │ produit par certains plus anciens │
│ │ │ référentiel-conversion │
│ │ outils. ??
?? ??
H │ tête (pointe de branche) │ │
│ │ s'engage │ │
?? ??
│O │ orphelin (sans parents) │ │
│ │ s'engage │ │
?? ??
│U │ commits avec des légendes comme │ │
│ parents │ │
?? ??
│Z │ commits sans fileops │ │
?? ??
│M │ fusionner (multi-parents) │ │
│ │ s'engage │ │
?? ??
F │ fourche (multi-enfants) │ │
│ │ s'engage │ │
?? ??
│L │ commet avec impur │ │
│ │ commentaires multilignes │ │
│ │ (sans séparation │ │
│ │ ligne vide après le │ │
│ d'abord) │ │
?? ??
│I │ s'engage pour qui │ │
│ │ les métadonnées ne peuvent pas être │ │
│ │ décodé en UTF-8 │ │
?? ??
T │ balises │ │
?? ??
│R │ réinitialise │ │
?? ??
│P │ Passthrough │ Tous les types d'événements simplement │
│ │ traversé, │
│ │ │ y compris les commentaires, │
│ │ le progrès commandes, et
│ │ point de contrôle commandes. ??
?? ??
│N │ Identifiants hérités │ Toute chaîne correspondant à un │
│ │ │ cookie (ancien ID) │
│ │ format. ??
?? ??


Un nom de référence (entre crochets) se résout en un seul objet, soit un
commit ou tag.

??
│ type │ l'interprétation │
??
│ nom de balise │ balise annotée avec ce nom │
??
│ nom de branche │ le commit de pointe de branche │
??
│ ID hérité │ commit avec cet ID hérité │
??
│nom attribué │ nom assimilé à une sélection par │
│ attribuer │
??
Notez que si une balise annotée et une branche ont le même nom foo, va résoudre
à la balise plutôt qu'au commit de pointe de branche.

dates et timbres d'action
Une date ou un cachet d'action entre crochets angulaires se résout en un ensemble de sélection de toutes les correspondances
s'engage.

?? ??
│ type │ l'interprétation │
?? ??
│ RFC3339 timestamp │ commit ou tag avec ça │
│ │ heure/date │
?? ??
timbre d'action (timestamp!email) │ commits ou balises avec cela │
│ │ horodatage et auteur (ou │
│ │ commiteur si pas d'auteur). ??
?? ??
│ aaaa-mm-jj partie de la RFC3339 │ tous les commits et balises avec cela │
│ horodatage │ date │
?? ??
Pour affiner la correspondance à un seul commit, utilisez un suffixe d'index à 1 origine séparé par « # ».
Ainsi, "<2000-02-06T09:35:10Z>" peut correspondre à plusieurs commits, mais
"<2000-02-06T09:35:10Z#2>" correspond uniquement au deuxième de l'ensemble.

recherche de texte
Une expression de recherche de texte est une expression régulière Python entourée de barres obliques
(pour y intégrer une barre oblique, utilisez un échappement de chaîne Python tel que \x2f).

Une recherche de texte correspond normalement aux champs de commentaire des commits et annotés
balises, ou contre leurs noms d'auteur/committer, ou contre les noms de balises ; également
texte d'objets passthrough.

La portée d'une recherche de texte peut être modifiée avec des lettres qualificatives après la fin
sabrer. Ce sont les suivants :

??
│lettre │ l'interprétation │
??
│ un │ nom d'auteur dans commit │
??
│ b │ nom de la branche dans commit ; aussi
│ │ correspond aux blobs référencés par │
│ │ s'engage sur les branches correspondantes, │
│ │ et les balises qui pointent vers des commits │
│ │ sur les branches de patch. ??
??
│ c │ texte de commentaire du commit ou de la balise │
??
│ r │ référence committish dans tag ou │
│ réinitialiser │
??
│ p │ texte en passthrough │
??
t │ tagueur dans tag │
??
│ n │ nom de la balise │
??
│ B │ contenu blob │
??
Plusieurs lettres de qualificatif peuvent ajouter plus de champs de recherche.

(Le qualificateur « b » remplace la syntaxe de l'ensemble de branches dans les versions antérieures de repurger.)

chemins
Une "expression de chemin" entre crochets se résout en l'ensemble de tous les commits et
blobs liés à un chemin correspondant à l'expression donnée. L'expression du chemin elle-même est
soit un littéral de chemin, soit une expression régulière entourée de barres obliques. Juste après
le / de fin d'une expression rationnelle de chemin, vous pouvez mettre n'importe quel nombre des caractères suivants
qui agissent comme des drapeaux : 'a', 'c', 'D', "M', 'R', 'C', 'N'.

Par défaut, un chemin est lié à un commit si ce dernier a un fileop qui touche cela
chemin du fichier - modifie qui le change, supprime qui le supprime, renomme et copie cela
l'avoir comme source ou cible. Lorsque le drapeau 'c' est utilisé, la signification change : le
les chemins liés à un commit deviennent tous les chemins qui seraient présents dans un checkout pour
qui s'engagent.

Un littéral de chemin correspond à un commit si et seulement si le littéral de chemin est exactement l'un des
chemins liés au commit (aucune opération de préfixe ou de suffixe n'est effectuée). En particulier un
Le littéral du chemin ne correspondra pas s'il correspond à un répertoire dans le référentiel choisi.

Une expression régulière correspond à un commit si elle correspond à un chemin lié au commit
n'importe où sur le chemin. Vous pouvez utiliser '^' ou '$' si vous voulez que l'expression ne corresponde qu'à
au début ou à la fin des chemins. Lorsque l'indicateur 'a' est utilisé, l'expression de chemin
sélectionne les commits dont chaque chemin correspond à l'expression régulière. Ce n'est pas toujours un
sous-ensemble de commits sélectionnés sans l'indicateur 'a' car il sélectionne également les commits avec
pas de chemins associés (par exemple, commits vides, deletealls et commits avec des arbres vides). Si tu
voulez éviter ceux-ci, vous pouvez utiliser par exemple '[/regex/] & [/regex/a]'.

Les drapeaux 'D', "M', 'R', 'C', 'N' restreignent la vérification de correspondance à l'opération de fichier correspondante
les types. Notez que cela signifie qu'une correspondance « a » est plus facile (pas plus difficile) à réaliser. Ceux-ci sont
no-iops lorsqu'il est utilisé avec 'c'.

Un chemin ou un littéral correspond à un blob s'il correspond à un chemin apparaissant dans un
fichierop de modification qui faisait référence à ce blob. Pour sélectionner des blobs purement correspondants ou
commits correspondants, composez une expression de chemin avec =B ou =C.

Si vous devez incorporer '[^/]' dans votre expression régulière (par exemple pour exprimer "tous
caractères mais une barre oblique"), vous pouvez utiliser une chaîne d'échappement Python telle que \x2f.

appels de fonction
Le langage d'expression a nommé des fonctions spéciales. La séquence pour une fonction nommée
est "@" suivi d'un nom de fonction, suivi d'un argument entre parenthèses. Présentement
les fonctions suivantes sont définies :

??
│prénom │ l'interprétation │
??
│min │ membre minimum d'une sélection │
│ ensemble │
??
│max │ membre maximum d'une sélection │
│ ensemble │
??
│amp │ jeu de sélection non vide devient │
│ │ tous les objets, l'ensemble vide est │
│ │ retourné vide │
??
│par │ tous les parents de commits dans le │
│ jeu d'arguments │
??
│chn │ tous les enfants de commits dans le │
│ jeu d'arguments │
??
│dsc │ tous les commits descendants du │
│ jeu d'arguments (jeu d'arguments │
│ inclus) │
??
│anc │ tout commet qui l'argument │
│ │ l'ensemble est issu de (argument │
│ set inclus) │
??
pre │ événements avant l'ensemble d'arguments ; ??
│ │ vide si l'argument défini │
│ │ inclut le premier événement. ??
??
│suc │ événements après l'ensemble d'arguments ; ??
│ │ vide si l'argument défini │
│ │ inclut le dernier événement. ??
??

Les expressions d'ensemble peuvent être combinées avec les opérateurs | et &; ceux-ci sont, respectivement, fixés
union et intersection. Le | a une priorité inférieure à l'intersection, mais vous pouvez utiliser
parenthèses '(' et ')' pour regrouper les expressions en cas d'ambiguïté (cela remplace le
accolades utilisées dans les anciennes versions de la syntaxe).

Toute opération définie peut être suivie de '?' pour ajouter les voisins et les référents des membres de l'ensemble.
Cela étend l'ensemble pour inclure les parents et les enfants de tous les commits dans l'ensemble, et
les référents de toutes les balises et réinitialisations de l'ensemble. Chaque référence de blob dans l'ensemble est
remplacé par tous les commits qui y font référence. Les '?' peut être répété pour étendre la
profondeur du voisinage.

Définissez la négation avec le préfixe ~ ; il a une priorité plus élevée que & et | mais inférieur à ?

IMPORTER ET EXPORTATION
repurger peut contenir plusieurs états de référentiel dans le noyau. Chacun a un nom. À tout moment
temps, un peut être sélectionné pour l'édition. Les commandes de ce groupe importent des référentiels, exportent
eux, et manipuler la liste in-core et la sélection.

lire [--format=fossile] [annuaire|-|<infile]
Avec un argument de nom de répertoire, cette commande tente de lire le contenu d'un
référentiel dans n'importe quel système de contrôle de version pris en charge sous ce répertoire ; lire sans
arguments le fait dans le répertoire courant. Si la sortie est redirigée vers un fichier simple,
il sera lu en tant que flux d'importation rapide ou fichier de vidage Subversion. Avec un argument de
"-", cette commande lit un flux d'importation rapide ou un fichier de vidage Subversion à partir du standard
input (cela sera utile dans les filtres construits avec des arguments de ligne de commande).

Si le contenu est un flux d'importation rapide, toute propriété "cvs-revision" sur un commit est
considéré comme une liste de cookies de révision CVS séparés par des sauts de ligne pointant vers le commit,
et utilisé pour le levage de référence.

Si le contenu est un flux d'importation rapide, toute propriété "legacy-id" sur un commit est prise
être un jeton d'ID hérité pointant vers le commit et utilisé pour la levée de référence.

Si l'emplacement de lecture est un référentiel git et contient un fichier .git/cvsauthors (tel que
est laissé en place par jet cvimport -A) ce fichier sera lu comme s'il avait été
donné au auteurs lire commander.

Si l'emplacement de lecture est un répertoire et que son sous-répertoire de référentiel contient un fichier nommé
legacy-map, ce fichier sera lu comme s'il était passé à une commande de lecture héritée.

Si l'emplacement de lecture est un fichier et que le --format=fossile est utilisé, le fichier est
interprété comme un référentiel de fossiles.

Le référentiel en lecture seule est ajouté à la liste des référentiels chargés et devient le
l'actuel, sélectionné pour la chirurgie. S'il a été lu à partir d'un fichier simple et que le nom du fichier
se termine par l'une des extensions .fi ou .svn, cette extension est supprimée du chargement
liste de noms.

Remarque : cette commande ne prend pas de jeu de sélection.

écrire [--legacy] [--format=fossile] [--noincremental] [--callout] [>sortir le fichier|-]
Vider les événements sélectionnés sous forme de flux d'importation rapide représentant le référentiel modifié ; les
l'ensemble de sélection par défaut est tous les événements. Où vider est la sortie standard s'il y a
aucun argument ou l'argument est '-', ou la cible d'une redirection de sortie.

Sinon, s'il n'y a pas de redirection et que l'argument nomme un répertoire, le
le référentiel est reconstruit dans ce répertoire, tout jeu de sélection étant ignoré ; si
ce répertoire cible n'est pas vide, son contenu est sauvegardé dans un répertoire de sauvegarde.

Si l'emplacement d'écriture est un fichier et que le --format=fossile est utilisé, le fichier est écrit
au format de dépôt de fossiles.

Avec la collection --héritage option, le Legacy-ID de chaque commit est ajouté à son commit
commentaire au moment de l'écriture. Cette option est principalement utile pour déboguer le bord de conversion
Cas.

Si vous spécifiez un jeu de sélection partiel tel que certains commits sont inclus mais leur
les parents ne le sont pas, la sortie inclura des cookies de vidage incrémentiels pour chaque branche avec
une origine en dehors du jeu de sélection, juste avant la première référence à cette branche dans
un engagement. Un cookie de vidage incrémentiel ressemble à "refs/heads/foo^0" et est un indice pour
chargeurs de flux d'exportation que la branche doit être collée à la pointe d'un préexistant
succursale du même nom. Les --noincrémental L'option supprime ce comportement.

Lorsque vous spécifiez un jeu de sélection partiel, l'inclusion d'un objet commit force le
inclusion de chaque blob auquel il fait référence et de chaque balise qui s'y réfère.

La spécification d'une sélection partielle peut provoquer une situation dans laquelle certaines marques parentes dans
les fusions ne correspondent pas aux commits présents dans le dump. Lorsque cela se produit et
--faire appel à option a été spécifiée, le code d'écriture remplace la marque de fusion par une légende,
le tampon d'action du commit parent ; sinon, la marque parente est omise. Importateurs
échouera lors de la lecture d'un vidage de flux avec des légendes ; il est destiné à être utilisé par le
greffer commander.

La spécification d'un jeu de sélection d'écriture avec des espaces est autorisée, mais il est peu probable qu'elle conduise à
de bons résultats s'il est chargé par un importateur.

Les extensions de propriété seront omises de la sortie si l'importateur pour le
le type de référentiel préféré ne peut pas les digérer.

Remarque : pour examiner de petits groupes de commits sans indicateur de progression, utilisez inspecter.

choisissez [renommer]
Choisissez un dépôt nommé sur lequel opérer. Le nom d'un dépôt est normalement le nom de base
du répertoire ou du fichier à partir duquel il a été chargé, mais les dépôts chargés à partir de l'entrée standard sont
"anonyme". repurger ajoutera un suffixe de désambiguïsation s'il y a eu plusieurs
lit de la même source.

Sans argument, répertorie les noms des référentiels actuellement stockés et leur charge
fois. La deuxième colonne est « * » pour le référentiel actuellement sélectionné, « - » pour les autres.

déposer [renommer]
Supprimez un dépôt nommé par l'argument de la liste de reposurgeon, libérant ainsi la mémoire utilisée pour
ses métadonnées et la suppression des blobs sur disque. Sans argument, supprime la valeur actuellement choisie
dépôt.

rebaptiser renommer
Renommez le référentiel actuellement choisi ; nécessite un argument. Je ne le ferai pas s'il y a
déjà un par le nouveau nom.

RECONSTRUIT IN PLACE
repurger peut reconstruire un référentiel modifié en place. Les fichiers non suivis sont normalement enregistrés
et restauré lorsque le contenu du nouveau référentiel est extrait (mais consultez le
documentation de la commande « conserver » pour une mise en garde).

reconstruire [annuaire]
Reconstruire un référentiel à partir de l'état détenu par repurger. Cette commande ne prend pas de
ensemble de sélection.

L'argument unique, s'il est présent, spécifie le répertoire cible dans lequel faire le
reconstruire; si le référentiel lu provenait d'un répertoire de référentiel (et non d'un git-import
stream), il utilise par défaut ce répertoire. Si le répertoire cible n'est pas vide, son
le contenu est sauvegardé dans un répertoire de sauvegarde. Fichiers et répertoires sur le référentiel
liste de conservation sont copiés à partir du répertoire de sauvegarde après la reconstruction du référentiel. Les
la liste de conservation par défaut dépend du type de référentiel et peut être affichée avec le
stats commander.

If repurger a une carte héritée non vide, elle sera écrite dans un fichier nommé
legacy-map dans le sous-répertoire du référentiel comme par une commande d'écriture héritée. (Cette
sera normalement le cas pour les conversions Subversion et CVS.)

préserver [fichier...]
Ajouter des fichiers ou des répertoires (vraisemblablement non suivis) à la liste des chemins d'accès du référentiel à
restauré à partir du répertoire de sauvegarde après un reconstruire. Chaque argument, le cas échéant, est
interprété comme un chemin d'accès. La liste de conservation actuelle s'affiche ensuite.

Il n'est nécessaire d'utiliser cette fonction que si votre système de contrôle de version ne dispose pas d'un
commande pour lister les fichiers sous contrôle de version. Dans les systèmes avec une telle commande (qui
inclure git et hg), tous les fichiers qui ne sont ni sous le répertoire dot du référentiel
ni sous reposurgeon, les répertoires temporaires ne sont conservés automatiquement.

déconserver [fichier...]
Supprimez les fichiers ou répertoires (vraisemblablement non suivis) de la liste des chemins d'accès du référentiel à
restauré à partir du répertoire de sauvegarde après un reconstruire. Chaque argument, le cas échéant, est
interprété comme un chemin d'accès. La liste de conservation actuelle s'affiche ensuite.

INFORMATION ET RAPPORTS
Les commandes de ce groupe rapportent des informations sur le référentiel sélectionné.

La sortie de ces commandes peut être redirigée individuellement vers un fichier de sortie nommé. Où
indiqué dans la syntaxe, vous pouvez préfixer le nom du fichier de sortie avec « > » et le donner comme un
argumentation suivante. Si vous utilisez ">>", le fichier est ouvert pour l'ajout plutôt que pour l'écriture.

liste [>fichier de sortie]
Il s'agit de la commande principale pour identifier les événements que vous souhaitez modifier. Il liste
commits dans la sélection définie par numéro de séquence d'événement avec des informations récapitulatives. Les
la première colonne contient les numéros d'événement bruts, la seconde un horodatage en heure locale. Si la
référentiel a des identifiants hérités, ils seront affichés dans la troisième colonne. Le premier
partie du commentaire suit.

timbre [>fichier de sortie]
Forme alternative de liste qui affiche des timbres d'action complets, utilisables comme références dans
sélections. Prise en charge > redirection.

pointe [>fichier de sortie]
Affichez les noms de pointe de branche associés aux commits dans l'ensemble de sélection. Ceux-ci seront
pas nécessairement les mêmes que leurs champs de branche (qui seront souvent des noms de balises si
le référentiel contient des balises annotées ou légères).

Si un commit est à une pointe de branche, sa pointe est son nom de branche. S'il n'a qu'un seul enfant,
sa pointe est la pointe de l'enfant. S'il a plusieurs enfants, alors s'il y a un enfant avec
un nom de branche correspondant, son pourboire est le pourboire de l'enfant. Sinon, cette fonction lance un
erreur récupérable.

étiquettes [>fichier de sortie]
Balises d'affichage et réinitialisations : trois champs, un numéro d'événement et un type et un nom. Branche
tip les commits associés aux balises sont également affichés avec le champ de type 'commit'.
Prise en charge > redirection.

stats [nom du dépôt...] [>fichier de sortie]
Statistiques de taille de rapport et informations de méthode d'importation/exportation sur les référentiels nommés,
ou sans argument le référentiel actuellement choisi.

compter [>fichier de sortie]
Signaler un nombre d'éléments dans l'ensemble de sélection. L'ensemble par défaut est tout dans le
repo actuellement sélectionné. Prise en charge > redirection.

inspecter [>fichier de sortie]
Videz un flux d'importation rapide représentant les événements sélectionnés vers la sortie standard. Tout comme un
écrire, sauf (1) le compteur de progression est désactivé, et (2) il y a un identifiant
en-tête avant chaque vidage d'événement.

graphique [>fichier de sortie]
Émettre une visualisation du graphe de validation dans le langage de balisage DOT utilisé par le
suite d'outils graphviz. Cela peut être fourni en entrée au programme de rendu principal de graphviz
point(1), ce qui donnera une image visible. Prise en charge > redirection.

Vous pouvez trouver un script comme celui-ci utile :

graphique $1 >/tmp/foo$$
point de coquille

Vous pouvez bien sûr utiliser votre propre visionneuse d'images préférée.

tailles [>fichier de sortie]
Imprimer un rapport sur le volume de données par succursale ; prend un jeu de sélection, par défaut à tous
événements. Les nombres correspondent à la taille des blobs non compressés, aux commentaires de validation et de balise, et
d'autres chaînes de métadonnées (un blob est compté à chaque fois qu'un commit pointe dessus).

Les chiffres ne sont pas une mesure exacte de la taille de stockage : ils sont principalement destinés à
moyen d'obtenir des informations sur la façon de partitionner efficacement un référentiel qui est devenu
assez grand pour être encombrant.

Prise en charge > redirection.

peluche [>fichier de sortie]
Recherchez les configurations de DAG et de métadonnées qui peuvent indiquer un problème. Vérifie actuellement
pour : (1) les suppressions en milieu de branche, (2) les commits déconnectés, (3) les commits sans parent, (4) le
existence de plusieurs racines, (5) identifiants de committer et d'auteur qui ne semblent pas bien formés
en tant qu'ID DVCS, (6) plusieurs liens enfants avec des étiquettes de branche identiques descendant du
même commit, (7) collisions d'heure et d'estampille d'action.

Les options permettant de n'émettre que des rapports partiels sont prises en charge ; "lint --options" ou "lint -?"
les répertorie.

Les options et le format de sortie de cette commande sont instables ; ils peuvent changer sans
remarquer que plus de contrôles de santé sont ajoutés.

CHIRURGICAL OPÉRATIONS
Ce sont les opérations que le reste du rechirurgien est conçu pour prendre en charge.

squash [politique...]
Combinez ou supprimez des commits dans un ensemble de sélection d'événements. La sélection par défaut définie pour
cette commande est vide. N'a aucun effet sur les événements autres que les commits à moins que --delete
la politique est sélectionnée ; voir la commande 'supprimer' pour discussion.

Normalement, lorsqu'un commit est écrasé, sa liste d'opérations de fichier (et tout blob associé
références) est soit précédé du début de la liste des opérations de chacun des
les enfants du commit ou ajoutés à la liste des opérations de chacun des commits
parents. Ensuite, les enfants d'un commit supprimé le sont supprimés de leur ensemble parent et
ses parents ajoutés à leur ensemble parent.

La valeur par défaut consiste à écraser vers l'avant, en modifiant les enfants ; mais voir la liste des politiques
modificateurs ci-dessous pour savoir comment changer cela.

Avertissement
Il est facile de se tromper sur les limites d'une commande de squash, avec des
résultats destructeurs. Méfiez-vous de penser que vous pouvez écraser un ensemble de sélections à fusionner
tous les commits sauf le dernier dans le dernier ; ce que vous ferez réellement, c'est de
fusionnez-les tous dans le premier commit après l'ensemble sélectionné.
Normalement, toute balise pointant vers un commit combiné sera également avancée. Mais voyez
la liste des modificateurs de politique ci-dessous pour savoir comment changer cela.

Après tous les mouvements d'opération, chacune des listes d'opérations de fichiers modifiées est
réduite à la forme normalisée la plus courte. La forme normalisée détecte divers
combinaisons de modification, suppression et renommage et simplifie l'opération
séquence autant que possible sans perdre aucune information.

Après la canonisation, une liste d'opérations de fichier peut toujours contenir plusieurs M
opérations sur le même fichier. Normalement, l'outil émet un avertissement lorsque cela se produit, mais
n'essaye pas de le résoudre.

Les modificateurs suivants modifient ces règles :

--effacer
Élimine simplement toutes les opérations de fichier et les balises associées aux commits supprimés.

--se fondre
Ignorez toutes les opérations M (et les blobs associés) sauf la dernière.

--repousser
Ajoutez des ops de fichier aux parents, plutôt que de les ajouter aux enfants.

--faire avancer
Ajouter des files d'attente aux enfants. C'est la valeur par défaut ; il peut être spécifié dans un ascenseur
script pour expliciter les intentions.

--tagforward
Avec le modificateur "tagforward", toute balise sur le commit supprimé est poussée en avant vers
le premier enfant plutôt que d'être supprimé. C'est la valeur par défaut ; ça peut être
spécifié pour l'explicitation.

--tagback
Avec le modificateur "--tagback", toute balise du commit supprimé est repoussée vers
le premier parent plutôt que d'être supprimé.

--silencieux
Supprime les messages d'avertissement concernant la suppression des commits avec des fichiers ops non supprimés.

--plaindre
Le contraire de calme. Peut être spécifié pour plus d'explicitation.

Sous l'une de ces politiques, à l'exception de "--delete", la suppression d'un commit qui a des enfants
n'annule pas les modifications apportées par ce commit, car elles seront toujours présentes dans
les blobs attachés aux versions après la fin de l'ensemble de suppression. Tout ce qu'une suppression fait
lorsque le commit a des enfants, on perd les informations de métadonnées sur quand et par qui
ces changements ont effectivement été apportés ; après la suppression, de tels changements seront attribués
aux premiers enfants non supprimés des commits supprimés. On s'attend à ce que ce
La commande sera utile principalement pour supprimer les commits générés mécaniquement par
convertisseurs de référentiel tels que cvs2svn.

delete [politique...]
Supprimer une sélection d'événements. La sélection par défaut définie pour cette commande est vide.
Sur un ensemble de commits, cela équivaut à un squash avec l'indicateur --delete. Ce
supprime inconditionnellement les balises, les réinitialisations et les relais ; les blobs peuvent être supprimés uniquement en tant que
effet secondaire de la suppression de chaque commit qui pointe vers eux.

diviser mère [enfant]
Tenter de partitionner un référentiel en coupant le lien parent-enfant entre deux spécifiés
commits (ils doivent être adjacents). Ne prend pas de jeu de sélection général. C'est seulement
nécessaire de spécifier le commit parent, sauf s'il a plusieurs enfants, auquel cas
le commit enfant doit suivre (séparez-le par une virgule).

Si le dépôt a été nommé « foo », vous vous retrouverez normalement avec deux dépôts nommés « foo-early »
et « foo-late » (les événements d'options et de fonctionnalités au début du premier segment seront
être dupliqué sur le début de la fin.). Mais si le graphe de validation
rester connecté par un autre chemin après la coupe, le comportement change. Dans ce
cas, si le parent et l'enfant étaient sur la même branche 'qux', les segments de branche sont
renommé 'qux-early' et 'qux-late' mais le repo n'est pas divisé.

effacer [chemin | /expression_reg/]...
Supprimer les fichiers de la partie sélectionnée de l'historique du dépôt ; la valeur par défaut est la totalité
l'histoire. Les arguments de cette commande peuvent être des chemins ou des expressions régulières Python
chemins correspondants (les expressions régulières doivent être marquées en étant entourées de //).

Toutes les opérations de modification de fichier (M) et de suppression (D) impliquant un fichier correspondant dans
l'ensemble d'événements sélectionné est déconnecté du référentiel et placé dans un ensemble de suppression.
Les changements de nom sont suivis au fur et à mesure que l'outil avance dans le jeu de sélection ; chacun déclenche un
message d'alerte. Si un fichier sélectionné est une cible de copie (C), la copie sera supprimée et
un message d'avertissement a été émis. Si un fichier sélectionné est une source de copie, la cible de copie sera
ajouté à la liste des chemins à supprimer et un avertissement émis.

Une fois les suppressions de fichiers effectuées, tous les commits sans aucune opération de fichier restante
seront supprimés, ainsi que toutes les balises pointant vers eux. S'engage avec des fileops supprimés pointant
à la fois à l'intérieur et à l'extérieur de l'ensemble de chemins ne sont pas supprimés, mais sont clonés dans l'ensemble de suppression.

Le kit de retrait n'est pas jeté. Il est assemblé dans un nouveau référentiel nommé d'après
l'ancien avec le suffixe "-expunges" ajouté. Ainsi, cette commande peut être utilisée pour sculpter
un référentiel en sections par correspondances de chemin de fichier.

tagifier [--canonicaliser] [--tipdelete] [--tagify-merge]
Recherchez des commits vides et transformez-les en balises. Prend un jeu de sélection facultatif
argument par défaut sur tous les commits. Pour chaque commit dans l'ensemble de sélection, transformez-le en
une balise avec le même message et les mêmes informations sur l'auteur si elle n'a pas d'opération de fichier. Par défaut
les commits de fusion ne sont pas pris en compte, même s'ils n'ont pas de fileops (donc pas d'arborescence
différences avec leur premier parent). Pour changer cela, utilisez le --tagify-merge option.

Le nom du tag généré sera 'emptycommit-ident', où ident est généré
à partir de l'ancien ID du commit supprimé, ou de sa marque, ou de son index dans le
référentiel, avec un suffixe de désambiguïsation si nécessaire.

Avec la collection --canonicaliser, tagify essaie plus difficilement de détecter les commits triviaux en premier
s'assurer que toutes les opérations de fichier des commits sélectionnés auront un effet réel lorsque
traitées par fast-import.

Avec la collection --tipdelete, tagify prend également en compte les conseils de branche avec uniquement deleteall fileops
être candidats à la taguée. Les balises correspondantes obtiennent les noms de la forme
'tipdelete-Nom de la filiale' plutôt que la valeur par défaut 'emptycommit-ident'.

Avec la collection --tagify-merge, tagify tagifie également les commits de fusion qui n'ont pas d'opération de fichier.
Lorsque cela est fait, le lien de fusion est déplacé vers le parent du commit yagified.

s'unir [--déboguer}|--changelog] [tempsfuzz]
Analyser l'ensemble de sélection pour les séries de commits avec des commentaires identiques proches les uns des autres
dans le temps (il s'agit d'une forme courante de tissus cicatriciels dans les conversions ascendantes du référentiel d'anciens
systèmes de contrôle de version orientés fichiers). Fusionnez ces cliques en supprimant tout sauf le
dernier commit, dans l'ordre ; les ops de fichiers des commits supprimés sont poussés vers celui-ci
le dernier

Le deuxième argument facultatif, s'il est présent, est une séparation de temps maximale en secondes ; les
la valeur par défaut est de 90 secondes.

La sélection par défaut définie pour cette commande est =C, tous les commits. Occasionnellement, vous pouvez
vouloir le restreindre, par exemple pour éviter de fusionner des cliques non liées de "*** vide
log message ***" commits à partir des ascenseurs CVS.

Avec l'option --debug, affiche les messages concernant les discordances.

Avec l'option --changelog, tout commit avec un commentaire contenant la chaîne 'vide
log message' (tel que celui généré par CVS) et contenant exactement une opération de fichier
la modification d'un chemin se terminant par ChangeLog est traitée spécialement. De tels commits ChangeLog sont
considéré comme correspondant à tout commit avant eux par le contenu, et fusionnera avec lui si
le committer correspond et la séparation des commits est suffisamment petite. Cette option gère un
convention utilisée par les projets de la Free Software Foundation.

scission {à|par} Articles
Le premier argument doit être un emplacement de validation ; la seconde est une préposition
qui indique la méthode de fractionnement à utiliser. Si la préposition est « à », alors le
le troisième argument doit être un entier index d'origine 1 d'une opération de fichier dans le
s'engager. Si c'est 'by', alors le troisième argument doit être un chemin d'accès pour être
correspondant au préfixe, la correspondance du chemin d'accès est effectuée en premier).

Le commit est copié et inséré dans une nouvelle position dans la séquence d'événements,
immédiatement après lui-même ; le duplicata devient l'enfant de l'original, et
le remplace en tant que parent des enfants de l'original. Les métadonnées de validation sont dupliquées ; les
la marque du nouveau commit est alors modifiée, avec 'bis' ajouté comme suffixe.

Enfin, certaines opérations sur les fichiers - en commençant par celui correspondant ou indexé par le fractionnement
argument - sont déplacés du commit d'origine vers le nouveau. Indices légaux
sont 2-n, où n est le nombre d'opérations de fichier dans le commit d'origine.

ajouter {D chemin | M permanente marque chemin | R source l'objectif C source l'objectif}
À partir d'un commit spécifié, ajoutez un fileop spécifié.

Pour qu'une opération D soit valide, il doit y avoir une opération M pour le chemin dans le
l'ascendance de commit. Pour qu'une opération M soit valide, la partie 'perm' doit être un jeton
se terminant par 755 ou 644 et la 'marque' doit faire référence à un blob qui précède le commit
emplacement. Pour qu'une opération R ou C soit valide, il doit y avoir une opération M pour le
source dans l'ascendance du commit.

supprimez [indice | chemin | suppressions] [à commettre]
À partir d'un commit spécifié, supprimez un fileop spécifié. L'opération doit être l'un des (a)
mot-clé « deletes », (b) un chemin de fichier, (c) un chemin de fichier précédé d'un ensemble de types d'opérations (certains
sous-ensemble des lettres DMRCN), ou (d) un index numérique à 1 origine. Le mot-clé "supprimer"
sélectionne tous les fichiers D dans le commit ; les autres en choisissent un chacun.

Si la clause "to" est présente, l'opération supprimée est ajoutée au commit spécifié par
l'ensemble de sélection singleton suivant. Cette option ne peut pas être combinée avec « supprimer ».

Notez que cette commande ne tente pas de nettoyer les blobs même si le fichier supprimé
pourrait être la seule référence à eux. Ce comportement peut changer dans une version future.

goutte
Créez un blob au repère :1 après avoir renuméroté les autres repères à partir de :2. Les données sont prises
de stdin, qui peut être un here-doc. Cela peut être utilisé avec la commande add pour patcher
données synthétiques dans un référentiel.

renuméroter
Renuméroter les marques dans un référentiel, de :1 à : où est le nombre de
dernière marque. Juste au cas où un importateur se soucierait de la commande des marques ou des lacunes dans le
séquence.

boîte aux lettres_out [>fichier de sortie]
Emettre un fichier boîte aux lettres de messages au format RFC822 représentant le contenu de
métadonnées du référentiel. Prend un jeu de sélection ; les membres de l'ensemble autres que les commits,
les balises annotées et les passthrough sont ignorés (c'est-à-dire actuellement, les blobs et les réinitialisations).

La sortie de cette commande peut éventuellement être redirigée vers un fichier de sortie nommé.
Préfixez le nom de fichier avec « > » et donnez-le comme argument suivant.

Peut avoir une option --filter, suivie de = et d'une expression régulière /-enclose. Si
ceci est donné, seuls les en-têtes avec des noms correspondants sont émis. Dans ce contexte le
le nom de l'en-tête comprend ses deux-points de fin.

boîte aux lettres_in [<dans le fichier] [--modifié >fichier de sortie]
Accepter un fichier boîte aux lettres de messages au format RFC822 représentant le contenu du
métadonnées dans les commits sélectionnés et les balises annotées. Ne prend aucun jeu de sélection. S'il y a
un argument qui sera pris comme nom d'un fichier de boîte aux lettres à lire ; pas d'argument,
ou l'un des "-" ; lit à partir de l'entrée standard.

Les utilisateurs doivent savoir que la modification d'un champ Numéro d'événement ou Marque d'événement changera
à quel événement la mise à jour de ce message est appliquée. Il est peu probable que cela ait une bonne
résultats.

Si les champs Event-Number et Event-Mark sont absents, la logique box_in
essayez de faire correspondre le commit ou la balise d'abord par Legacy-ID, puis par un ID de commiter unique
et la paire d'horodatage.

Si la sortie est redirigée et que le modificateur "--changed" apparaît, un ensemble minimal de
les modifications réellement apportées sont écrites dans le fichier de sortie sous une forme qui peut être alimentée
de retour

champ de définition attribuer Plus-value
Dans les objets sélectionnés (aucune valeur par défaut), définissez chaque instance d'un champ nommé sur un
valeur de chaîne. La chaîne peut être entre guillemets pour inclure des espaces et utiliser une barre oblique inverse
les échappements interprétés par le codec d'échappement de chaîne Python, tels que \n et \t.

Les tentatives de définition d'attributs inexistants sont ignorées. Les valeurs valides pour l'attribut sont
noms de champs Python internes ; en particulier, pour les commits, "comment" et "branch" sont
légal. Consultez le code source pour d'autres valeurs intéressantes.

ajouter [--rstrip] [>texte]
Ajoute du texte aux commentaires des commits et des balises dans le jeu de sélection spécifié. Les
text est le premier jeton de la commande et peut être une chaîne entre guillemets. Évasion de style C
les séquences de la chaîne sont interprétées à l'aide du codec string_decode de Python.

Si l'option --rstrip est donnée, le commentaire est supprimé à droite avant que le nouveau texte ne soit
ajouté

une fonction filtre [--coquille|--expression régulière|--remplacer|--dedos]
Exécuter des blobs, valider des commentaires ou baliser des commentaires dans la sélection définie via le filtre
spécifié sur la ligne de commande.

Dans n'importe quel mode autre que --dedos, tenter de spécifier un jeu de sélection comprenant à la fois
les blobs et les non-blobs (c'est-à-dire les commits ou les balises) renvoient une erreur. Contenu en ligne dans
les commits sont filtrés lorsque l'ensemble de sélection contient (uniquement) des blobs et que le commit est
dans la plage délimitée par le blob le plus ancien et le plus récent dans la spécification.

Lors du filtrage des blobs, si la ligne de commande contient le cookie magique '%PATHS%' c'est
remplacé par une liste séparée par des espaces de tous les chemins qui font référence au blob.

Avec --shell, le reste de la ligne spécifie un filtre en tant que commande shell. Chaque
blob ou commentaire est présenté au filtre sur l'entrée standard ; le contenu est remplacé
avec tout ce que le filtre émet à la sortie standard. À l'heure actuelle, --shell est requis.
D'autres modes de filtrage seront pris en charge à l'avenir.

Avec --regex, le reste de la ligne devrait être une expression régulière Python
substitution écrite comme /from/to/ avec from et to étant passés comme arguments au
fonction re.sub () standard et appliquée pour modifier le contenu. En fait, tout
le caractère non espace fonctionnera comme délimiteur à la place du /; cela rend plus facile
utiliser / dans les motifs. Ordinairement, seule la première de ces substitutions est effectuée ;
mettre 'g' après que la barre oblique remplace globalement, et un littéral numérique donne le maximum
nombre de remplacements à effectuer. D'autres indicateurs disponibles restreignent la portée de la substitution
- 'c' pour le texte du commentaire uniquement, 'C' pour le nom de l'auteur uniquement, 'a' pour les noms des auteurs uniquement.

Avec --replace, le comportement est comme --regexp mais les expressions ne sont pas interprétées
comme expressions régulières. (C'est légèrement plus rapide).

Avec --dedos, les fins de ligne \r\n de style DOS/Windows sont remplacées par \n.

Transcoder codec
Transcodez les blobs, commitez les commentaires et les noms des commiteurs/auteurs, ou étiquetez les commentaires et étiquetez
noms de committer dans la sélection définie sur UTF-8 à partir du codage de caractères spécifié sur
la ligne de commande.

Tenter de spécifier un jeu de sélection comprenant à la fois des blobs et des non-blobs (c'est-à-dire,
commits ou tags) renvoie une erreur. Le contenu en ligne dans les commits est filtré lorsque le
l'ensemble de sélection contient (uniquement) des blobs et le commit est dans la plage délimitée par le
premier et dernier blob dans la spécification.

L'argument d'encodage doit nommer l'un des codecs connus des codecs standard Python
une bibliothèque. En particulier, « latin-1 » est un nom de codec valide.

Les erreurs dans cette commande sont fatales, car une erreur peut laisser des objets de référentiel dans un
état endommagé.

La théorie derrière la conception de cette commande est que le référentiel peut contenir un
mélange d'encodages utilisés pour saisir les métadonnées de commit par différentes personnes à différents
fois. Après avoir utilisé =I pour identifier les métadonnées contenant des octets de poids fort non Unicode dans le texte,
un humain doit utiliser le contexte pour identifier quels encodages particuliers ont été utilisés dans
s'étend sur des événements particuliers et composez les commandes de transcodage appropriées pour les corriger.

éditer
Signaler l'ensemble de sélection d'événements à un fichier temporaire comme le fait box_out, appelez un éditeur
dessus, et mettez à jour à partir du résultat comme le fait box_in. Si vous ne spécifiez pas d'éditeur
name comme deuxième argument, il sera tiré de la variable $EDITOR dans votre
sûr et sécurisé.

Normalement, cette commande ignore les blobs car boîte aux lettres_out Est-ce que. Cependant, si vous spécifiez
un jeu de sélection constitué d'un seul blob, votre éditeur sera appelé directement sur
le fichier blob.

décalage horaire décalage [fuseau horaire]
Appliquez un décalage horaire à tous les horodatages de l'ensemble sélectionné. Un argument de décalage est
obligatoire; il peut être sous la forme [+-]ss, [+-]mm:ss ou [+-]hh:mm:ss. Le signe principal est
nécessaire pour la distinguer d'une expression de sélection.

En option, vous pouvez également spécifier un autre argument sous la forme [+-]hhmm, un fuseau horaire
littéral à appliquer. Pour appliquer un fuseau horaire sans décalage, utilisez un littéral de décalage de +0
ou -0.

unir [--prune] renommer...
Unifier les référentiels. Nommez un nombre quelconque de référentiels chargés ; ils seront unis en
un dépôt syndical et retiré de la liste de chargement. La pension syndicale sera sélectionnée.

La racine de chaque repo (autre que la repo la plus ancienne) sera greffée en tant qu'enfant sur la
dernier commit dans le dump avec une date de commit précédente. Exécuter du dernier au premier, dupliquer
les noms seront désambiguïsés en utilisant le nom du référentiel source (ainsi, les doublons récents
auront la priorité sur les plus anciens). Après toutes les greffes, les marques seront renumérotées.

Le nom du nouveau repo sera le nom de toutes les parties concaténées, séparées par
'+'. Il n'aura pas de répertoire source ou de type de système préféré.

Avec l'option --prune, à chaque jointure D opérations pour chaque fichier ancestral existant
sera ajouté au début du commit racine, puis il sera canonisé en utilisant les règles
pour écraser l'effet sera que seuls les fichiers avec M, R et C correspondant correctement
les opérations dans la racine survivent.

greffer [--prune] renommer
Car quand unit ne vous donne pas assez de contrôle. Cette commande peut avoir l'un des deux
formulaires, sélectionnés par la taille du jeu de sélection. Le premier argument est toujours
doit être le nom d'un dépôt chargé.

Si le jeu de sélection est de taille 1, il doit identifier un seul commit dans le
pension choisie; dans ce cas, le nom de la racine du référentiel deviendra un enfant du spécifié
s'engager. Si l'ensemble de sélection est vide, le référentiel nommé doit contenir un ou plusieurs
les appels correspondant à un commit dans le référentiel actuellement choisi.

Les étiquettes et les branches du référentiel nommé sont précédées de son nom ; puis il est greffé
à celui sélectionné. Tous les autres appels dans le référentiel nommé sont également résolus dans le
contexte de celui actuellement choisi. Enfin, le référentiel nommé est supprimé du chargement
liste.

Avec l'option --prune, ajoutez une opération deleteall à la racine du greffé
dépôt.

chemin [source] rebaptiser [--Obliger}] [l'objectif]
Renommez un chemin dans chaque fileop de chaque commit sélectionné. Le jeu de sélection par défaut est
tous les commits. Le premier argument est interprété comme une expression régulière Python pour correspondre
contre les chemins; le second peut contenir une syntaxe de référence arrière.

Normalement, si le chemin cible existe déjà dans le fichier ops, ou est visible dans le
ascendance du commit, cette commande renvoie une erreur. Avec le --Obliger option, ces
les contrôles sont ignorés.

chemins [{sous|sup}] [dis-moi] [>fichier de sortie]
Prend un jeu de sélection. Sans modificateur, répertoriez tous les chemins touchés par les ops de fichiers dans le
ensemble de sélection (qui par défaut est le référentiel entier). Cette variante de rapport ne
>-redirection.

Avec le modificateur 'sub', prenez un deuxième argument qui est un nom de répertoire et ajoutez le préfixe
il à chaque chemin. Avec le modificateur 'sup', supprimez le premier composant de répertoire de
chaque chemin.

fusionner
Créez un lien de fusion. Prend un argument de jeu de sélection, en ignorant tout sauf le plus bas
(source) et les membres les plus élevés (cible). Crée un lien de fusion à partir du membre le plus élevé
(enfant) au plus bas (parent).

annuler la fusion
Linéariser un commit. Prend un argument de jeu de sélection, qui doit se résoudre en un seul
commit, et supprime tous ses parents sauf le premier.

C'est équivalent à réparerpremier_parent,commettrerebasement, Où commettre est le même
jeu de sélection tel qu'il est utilisé avec l'annulation de la fusion et premier_parent est un ensemble résolvant commettreen premier
parent (voir le réparer commande ci-dessous

Le principal intérêt de la annuler la fusion c'est que vous n'avez pas à trouver et à spécifier le premier
parent vous-même, en économisant du temps et en évitant les erreurs lorsqu'une intervention chirurgicale à proximité ferait un
manuel du premier argument parent périmé.

réparer [rebasement]
Modifie la liste des parents d'un commit. Prend un argument de jeu de sélection et une option
argumentation politique. L'ensemble de sélection doit résoudre exactement deux commits, le dernier de
qui est le commit à modifier, et le plus ancien est le nouveau premier parent. Tous les autres
les liens des parents sont effacés ; si vous le souhaitez, vous pouvez les recréer avec la commande 'merge'.

Par défaut, le manifeste du commit reparenté est calculé avant de le modifier ; une
deleteall et fileops sont préfixés afin que le manifeste reste inchangé même lorsque le
le premier parent a été changé. L'utilisation du mot-clé 'rebase' comme troisième argument inhibe
ce comportement - aucun deleteall n'est et le contenu de l'arborescence de tous les descendants peut être
modifié en conséquence.

une succursale Nom de la filiale... {rebaptiser|delete} [arg]
Renommer ou supprimer une branche (et toutes les réinitialisations associées). Le premier argument doit être un
nom de la succursale existante ; le deuxième argument doit être l'un des verbes « renommer » ou « supprimer ».

Pour un « renommer », le troisième argument peut être n'importe quel jeton qui est une syntaxe valide
nom de la branche (mais pas le nom d'une branche existante). Pour un 'supprimer', pas de troisième
un argumentaire est requis.

Pour l'un ou l'autre nom, s'il ne contient pas de '/', le préfixe 'refs/heads' est ajouté au début.

Étiquette nom de balise... {déplacer|renommer|supprimer} [argument].
Déplacer, renommer ou supprimer une balise. Le premier argument doit être un nom de balise existant ; seconde
l'argument doit être l'un des verbes « déplacer », « renommer » ou « supprimer ».

Pour un "déplacement", un troisième argument doit être un ensemble de sélection singleton. Pour un « renommer », le
le troisième argument peut être n'importe quel jeton qui est un nom de balise syntaxiquement valide (mais pas le
nom d'une balise existante). Pour une « suppression », aucun troisième argument n'est requis.

Le comportement de cette commande est complexe car les fonctionnalités qui se présentent sous forme de balises peuvent être
l'une des trois choses suivantes : (1) objets de balises vraies, (2) balises légères, en fait des séquences de
commits avec un nom de branche commun commençant par « refs/tags » - dans ce cas, la balise est
considéré comme pointant vers le dernier commit de la séquence, (3) Réinitialiser les objets. Ceux-ci peuvent
se produire en combinaison ; en fait, les exportateurs de flux à partir de systèmes avec des balises d'annotation
expriment généralement chacun d'eux sous la forme d'un véritable objet de balise (1) pointant vers la pointe de validation de
une séquence (2) dans laquelle le nom de base du champ de branche commun est identique au
nom de la balise. Un exportateur qui génère des séquences de validation avec des balises légères (2) peut ou
ne peut pas générer de réinitialisations pointant vers leurs commits de pointe.

Cette commande essaie de gérer toutes les combinaisons de manière naturelle en effectuant jusqu'à trois
opérations sur n'importe quelle vraie balise, séquence de validation et réinitialisation correspondant au nom de la source. Dans un
renommer, tous sont renommés ensemble. Lors d'une suppression, toute balise ou réinitialisation correspondante est supprimée ;
puis les champs de branche correspondants sont modifiés pour correspondre à la branche du descendant unique
du commit tagué, s'il y en a un. Lorsqu'une balise est déplacée, aucun champ de branche n'est
changé et un avertissement est émis.

Les tentatives de suppression d'une balise légère peuvent échouer avec le message « Impossible de déterminer un
successeur unique ». Lorsque cela se produit, la balise est sur un commit avec plusieurs enfants
qui ont des étiquettes de branche différentes. Il y a un trou dans la spécification de git
flux d'importation rapide qui ne permettent pas de savoir comment les étiquettes de branche peuvent être en toute sécurité
réaffecté dans ce cas ; plutôt que de faire quelque chose de risqué, repurger jette un
erreur récupérable.

réinitialiser réinitialiser le nom... {déplacer|renommer|supprimer} [argument].
Déplacer, renommer ou supprimer une réinitialisation. Le premier argument doit correspondre à un nom de réinitialisation existant ;
le deuxième argument doit être l'un des verbes « déplacer », « renommer » ou « supprimer ».

Pour un "déplacement", un troisième argument doit être un ensemble de sélection singleton. Pour un « renommer », le
le troisième argument peut être n'importe quel jeton qui correspond à un nom de réinitialisation syntaxiquement valide
(mais pas le nom d'une réinitialisation existante). Pour une « suppression », aucun troisième argument n'est
nécessaire.

Pour l'un ou l'autre nom, s'il ne contient pas de "/", le préfixe "heads/" est ajouté au début. Si ça
ne commence pas par "refs/", "refs/" est préfixé.

Un argument correspond au nom d'une réinitialisation s'il s'agit soit de la référence entière
(refs/heads/FOO ou refs/tags/FOO pour une certaine valeur de FOO) ou le nom de base (par exemple
FOO), ou un suffixe de la forme head/FOO ou tags/FOO. Un nom de base non qualifié est
supposé se référer à une tête.

Lorsqu'une réinitialisation est renommée, les champs de branche de validation correspondant à la balise sont renommés avec elle en
rencontre. Lorsqu'une réinitialisation est supprimée, les champs de branche correspondants sont modifiés pour correspondre à la branche
du descendant unique du tip commit de la branche associée, s'il y en a un.
Lorsqu'une réinitialisation est déplacée, aucun champ de branche n'est modifié.

débrancher branche-source... [branche-cible].
Prend un ou deux arguments qui doivent être les noms des branches source et cible ; si
le deuxième argument (cible) est omis, sa valeur par défaut est refs/heads/master. Toute traînée
segment d'un nom de branche est accepté comme synonyme de celui-ci ; donc maître est le même que
réfs/chefs/maître. Ne prend pas de jeu de sélection.

L'historique de la branche source est fusionné avec l'historique de la branche cible,
devenir l'historique d'un sous-répertoire avec le nom de la branche source. Toute réinitialisation
de la branche source sont supprimés.

bande [blobs|réduire].
Réduisez le référentiel sélectionné pour en faire un cas de test plus facile à gérer. Utilisez ceci lorsque
signaler des bogues.

Avec le modificateur 'blobs', remplacez chaque blob du référentiel par un petit,
stub auto-identifiant, laissant intactes toutes les métadonnées et la topologie DAG. C'est utile
lorsque vous signalez un bogue, pour réduire les grands référentiels à des cas de test de
taille gérable.

Un jeu de sélection n'est efficace qu'avec l'option 'blobs', par défaut tous les blobs.
Le mode 'réduire' agit toujours sur l'ensemble du référentiel.

Avec le modificateur 'réduire', effectuez une réduction topologique qui rejette
commits inintéressants. Si un commit a toutes les modifications de fichiers (pas de suppressions ou de copies
ou renomme) et a exactement un ancêtre et un descendant, alors cela peut être ennuyeux. À
être complètement ennuyeux, il ne doit pas non plus être référencé par une étiquette ou une réinitialisation. Intéressant
les commits ne sont pas ennuyeux, ou ont un parent ou un enfant non ennuyeux.

Sans modificateurs, cette commande supprime les blobs.

ne tient pas compte [renommer]. [Traduire]. [valeurs par défaut].
Gestion intelligente des fichiers de modèle d'ignorer. Cette commande échoue si aucun référentiel n'a
été sélectionné ou aucun type d'écriture préféré n'a été défini pour le référentiel. Ce ne est pas
prendre un jeu de sélection.

Si le modificateur rename est présent, cette commande tente de renommer tous les ignorer-pattern
fichiers à tout ce qui est approprié pour le type préféré - par exemple .gitignore pour git,
.hgignore pour hg, etc. Cette option ne provoque aucune traduction des fichiers ignorés
il renomme.

Si le modificateur translate est présent, la traduction syntaxique de chaque fichier ignoré est
tenté. À l'heure actuelle, la seule transformation connue du code consiste à ajouter une syntaxe " :
en-tête glob' si le type préféré est hg.

Si le modificateur de valeurs par défaut est présent, la commande tente de préfixer ces valeurs par défaut
modèles à tous ignorer les fichiers. Si aucun fichier ignoré n'est créé par le premier commit, il
sera modifié pour en créer un contenant les valeurs par défaut. Cette commande générera une erreur sur
préférez les types qui n'ont pas de modèles d'ignorer par défaut (git et hg, en particulier). Ce sera
également une erreur lorsqu'il sait que l'outil d'importation a déjà défini des modèles par défaut.

RÉFÉRENCE LEVAGE
Ce groupe de commandes est destiné à corriger les références dans les commits au format
des anciens systèmes de contrôle de version. Le flux de travail général est le suivant : tout d'abord, passez en revue le commentaire
l'historique et changez toutes les références de validation à l'ancienne en cookies analysables par machine.
Ensuite, transformez automatiquement le cookie analysable par machine en tampons d'action. Le point de
en divisant le processus de cette façon, la première partie est difficile à maîtriser pour une machine,
tandis que la deuxième partie est sujette aux erreurs lorsqu'un humain le fait.

Un cookie Subversion est une sous-chaîne de commentaires de la forme [[SVN:ddddd]] (exemple :
[[SVN:2355]] avec la révision lue directement via l'exportateur Subversion, déduite de
métadonnées git-svn, ou correspondant à un en-tête $Revision$ intégré dans les données blob pour le nom de fichier.

Un cookie CVS est une sous-chaîne de commentaires de la forme [[CVS:filename:revision]] (exemple :
[[CVS:src/README:1.23]] avec la révision correspondant à un en-tête CVS $Id$ ou $Revision$
incorporé dans les données blob pour le nom de fichier.

Un cookie de marque est de la forme [[:dddd]] et est simplement une référence à la marque spécifiée.
Vous voudrez peut-être le corriger manuellement lorsque l'un des formulaires précédents ne vous convient pas.

Un tampon d'action est un horodatage RFC3339, suivi d'un '!', suivi d'un e-mail d'auteur
adresse (auteur plutôt que committer car cet horodatage n'est pas modifié lorsqu'un patch
est rejoué sur une branche). Il tente de faire référence à un commit sans être spécifique à VCS.
Ainsi, au lieu de "commit 304a53c2" ou "r2355", "2011-10-25T15:11:09Z ![email protected]".

Les alias git suivants permettent à git de travailler directement avec les tampons d'action. Ajoutez-le à votre
~ / .gitconfig; si vous avez déjà une section [alias], omettez la première ligne.

[alias]
# timbre git - imprimer un timbre d'action de style réchirurgical
tampon = show -s --format='%cI!%ce'

# git scommit - liste le commit le plus récent qui correspond .
# Doit également spécifier une branche à rechercher ou --all, après ces arguments.
scommit = "!f(){ d=${1%%!*}; a=${1##*!}; arg=\"--until=$d -1\"; if [ $a ! = $1 ]; then arg=\"$arg --committer=$a\"; fi; shift; git rev-list $arg ${1:+\"$@\"}; }; f"

# git scommit - comme ci-dessus, mais liste tous les commits correspondants.
scommits = "!f(){ d=${1%%!*}; a=${1##*!}; arg=\"--until=$d --after $d\"; if [ $a != $1 ]; then arg=\"$arg --committer=$a\"; fi; shift; git rev-list $arg ${1:+\"$@\"}; }; f"

# git smaster - liste le commit le plus récent sur le maître qui correspond .
smaster = "!f(){ git scommit \"$1\" master --first-parent; }; f"
smasters = "!f(){ git scommits \"$1\" master --first-parent; }; f"

# git shs - afficher les commits sur le maître qui correspondent .
shs = "!f(){ stamp=$(git smasters $1); shift; git show ${stamp:?not found} $*; }; f"

# git slog - démarrer git log à sur le maître
slog = "!f(){ stamp=$(git smaster $1); shift; git log ${stamp:?not found} $*; }; f"

# git sco - vérifier le commit le plus récent sur le maître qui correspond .
sco = "!f(){ stamp=$(git smaster $1); shift; git checkout ${stamp:?not found} $*; }; f"

Il existe de rares cas dans lesquels un tampon d'action ne se réfère pas uniquement à un commit. Il est
théoriquement possible que le même auteur puisse enregistrer des révisions sur différentes branches
dans la résolution d'une seconde des horodatages dans un flux d'importation rapide. Il y a
rien à faire à ce sujet ; les outils utilisant des vignettes d'action doivent être conscients de la
possibilité et lancer un avertissement quand cela se produit.

Afin de prendre en charge le levage de référence, repurger construit en interne une référence héritée
map qui associe les identifiants de révision dans les anciens systèmes de contrôle de version aux commits.
Le contenu de cette carte provient de trois endroits : (1) cvs2svn:rev properties si le
référentiel a été lu à partir d'un flux de vidage Subversion, (2) en-têtes $Id$ et $Revision$ dans
les fichiers du référentiel et (3) les révisions .git/cvs créées par jet cvimport.

La séquence détaillée pour lever les références possibles est la suivante : d'abord, trouvez les CVS possibles
et les références Subversion avec le ou =N ensemble de visibilité ; puis remplacez-les par
cookies équivalents ; puis cours . pour transformer les cookies en timbres d'action (en utilisant
les informations dans la carte de référence héritée) sans avoir à faire la recherche à la main.

[liste|éditer|.] [>fichier de sortie]
Avec le modificateur 'list', listez les commits et balisez les commentaires pour les chaînes qui pourraient être CVS-
ou des identificateurs de révision de style Subversion. Cela vous sera utile lorsque vous voudrez remplacer
les avec des cookies équivalents qui peuvent être automatiquement traduits en VCS-indépendant
timbres d'action. Cette commande de rapport prend en charge la >-redirection. C'est équivalent à '=N
liste'.

Avec le modificateur 'edit', éditez l'ensemble où se trouvent les ID de révision. C'est
équivalent à '=N édition'.

Avec le modificateur "lift", essayez de résoudre les cookies Subversion et CVS dans les commentaires
en timbres d'action à l'aide de la carte héritée. Un timbre d'action est un
combinaison horodatage/e-mail/numéro de séquence identifiant de manière unique le commit associé
avec ce blob, comme décrit dans la section intitulée « STYLE DE TRADUCTION ».

Il n'est pas garanti que chaque référence de ce type sera résolue, ni même qu'aucune au
tout sera. Normalement, toutes les références de l'historique d'un dépôt Subversion seront
résoudre, mais les références CVS sont moins susceptibles d'être résolues.

MACRO ET EXTENSIONS
Occasionnellement, vous devrez émettre un grand nombre d'ordres chirurgicaux complexes de très
formulaire similaire, et il est pratique de pouvoir emballer ce formulaire afin que vous n'ayez pas besoin de le faire
beaucoup de frappes sujettes aux erreurs. Pour ces occasions, repurger prend en charge une forme simple de
extension de macros.

Vous permet de définir prénom corps
Définir une macro. Le premier jeton séparé par des espaces est le nom ; le reste de la
line est le corps, à moins qu'il ne s'agisse de "{", qui commence une macro multiligne terminée par un
ligne commençant par "}".

Un appel « do » ultérieur peut invoquer cette macro.

La commande "définir" par elle-même sans nom ni corps produit une liste de macros.

do prénom arguments...
Développez et exécutez une macro. Le premier jeton séparé par des espaces est le nom du
macro à appeler ; les jetons restants remplacent {0}, {1}... dans la définition de la macro (le
les conventions utilisées sont celles de la méthode du format Python). Les jetons peuvent contenir des espaces
s'ils sont entre guillemets ; les guillemets de chaîne sont supprimés. Les macros peuvent appeler des macros.

Si l'expansion de la macro ne commence pas elle-même par un jeu de sélection, quel que soit le jeu
spécifié avant que le mot-clé "do" ne soit disponible pour la commande générée par le
vous propose d’explorer.

indéfinir prénom]
Dédéfinissez la macro nommée.

Voici un exemple pour illustrer comment vous pourriez l'utiliser. Dans les référentiels CVS des projets
qui utilisent la convention GNU ChangeLog, un artefact de pré-conversion très courant est un commit
avec le commentaire "*** message de journal vide***" qui modifie uniquement une entrée ChangeLog expliquant
le commit qui le précède immédiatement. Ce qui suit

définir le journal des modifications <{0}> & / message de journal vide/ écraser --pushback
do changelog 2012-08-14T21:51:35Z
do changelog 2012-08-08T22:52:14Z
do changelog 2012-08-07T04:48:26Z
do changelog 2012-08-08T07:19:09Z
do changelog 2012-07-28T18:40:10Z

est équivalent au plus verbeux

<2012-08-14T21:51:35Z> & /message de journal vide/ squash --pushback
<2012-08-08T22:52:14Z> & /message de journal vide/ squash --pushback
<2012-08-07T04:48:26Z> & /message de journal vide/ squash --pushback
<2012-08-08T07:19:09Z> & /message de journal vide/ squash --pushback
<2012-07-28T18:40:10Z> & /message de journal vide/ squash --pushback

mais vous êtes moins susceptible de faire des erreurs difficiles à remarquer en tapant la première version.

(Notez également comment l'expression rationnelle de texte agit comme une sécurité intégrée contre la possibilité de taper un
mauvaise date qui ne fait pas référence à un commit avec un commentaire vide. C'était un monde réel
exemple de la conversion CVS en git de groff.)

Lorsque même une macro ne suffit pas, vous pouvez écrire et appeler des extensions Python personnalisées.

exec prénom
Exécutez le code personnalisé à partir de l'entrée standard (normalement un fichier via < redirection). Utilisez ceci
pour configurer des fonctions d'extension personnalisées pour les appels d'évaluation ultérieurs. Le code a un accès complet à
toutes les structures de données internes. Les fonctions définies sont accessibles ultérieurement eval appels.

Cela peut être appelé dans un script avec le code d'extension dans un here-doc.

eval nom-fonction
Évalue une ligne de code dans le contexte actuel de l'interpréteur. Typiquement, ce sera un
appel à une fonction définie par un exec précédent. Les variables _dépôt et
_sélection aura les valeurs évidentes. Noter que _sélection sera une liste de
des entiers, pas des objets.

ARTEFACT RETRAITS
Certaines commandes automatisent la correction de divers types d'artefacts associés au référentiel
conversions à partir des systèmes de commande.

auteurs [lire|écrire] [nom de fichier] [>nom de fichier]
Appliquer ou vider les informations de mappe d'auteur pour l'ensemble de sélection spécifié, par défaut
tous les évènements.

Les ascenseurs de CVS et Subversion peuvent n'avoir que des noms d'utilisateur locaux sur l'hôte du référentiel dans
les identifiants de commiter et d'auteur. Les DVCS veulent des adresses e-mail (identifiants à l'échelle du réseau) et
noms complets. Pour alimenter la carte de l'un à l'autre, un fichier auteurs est prévu
se composer de lignes commençant chacune par un identifiant d'utilisateur local, suivi d'un '=' (éventuellement
entouré d'espaces) suivi d'un nom complet et d'une adresse e-mail, éventuellement
suivi d'un champ de décalage de fuseau horaire. Ainsi:

ferd = Ferd J. Foonly[email protected]> -0500

Un fichier d'auteur peut avoir des lignes de commentaires commençant par '#' ; ceux-ci sont ignorés.

Lorsqu'un fichier d'auteur est appliqué, les adresses e-mail dans les métadonnées de committer et d'auteur pour
dont l'ID local correspond entre < et @ sont remplacés en fonction du mappage (cet
gère les ascenseurs git-svn). Alternativement, si l'ID local est l'adresse entière, c'est
également considéré comme une correspondance (cela gère ce que font git-cvsimport et cvs2git)

Avec le modificateur 'read', ou pas de modificateur, appliquez les données de mappage de l'auteur (à partir de
input ou un fichier <-redirected). Peut être utile si vous éditez un dépôt ou un dump créé
by cvs2git ou git-svn invoqué sans -A.

Avec le modificateur 'write', écrivez un fichier de mappage qui pourrait être interprété par auteurs
lire, avec des entrées pour chaque committer, auteur et tagueur unique (vers la sortie standard
ou un fichier de mappage <-redirected). Cela peut être utile pour commencer à créer un auteur
fichier, bien que chaque partie à droite d'un signe égal devra être modifiée.

se brancher [chemin d'accès]
Précisez la liste des répertoires à traiter comme des branches potentielles (pour devenir des balises si
il n'y a pas de modifications après la création des copies) lors de l'analyse d'une Subversion
repo. Cette liste est ignorée lorsque le --nobranche l'option de lecture est utilisée. Il est par défaut le
ensemble de répertoires « mise en page standard », ainsi que tous les répertoires non reconnus dans le
racine du référentiel.

Sans arguments, affiche l'ensemble de branchification actuel.

Un astérisque à la fin d'un chemin dans l'ensemble signifie « tous les sous-répertoires immédiats de
ce chemin, à moins qu'ils ne fassent partie d'un autre chemin (plus long) dans l'ensemble branchify'.

Notez que l'ensemble branchify est une propriété de l'interpréteur de reposurgeon, pas de n'importe quel
référentiel individuel, et persistera à travers les lectures de fichiers de vidage Subversion. Ceci peut
conduire à des résultats inattendus si vous oubliez de le réinitialiser.

branchify_map [/regex/branche/...]
Spécifiez la liste des expressions régulières utilisées pour mapper les branches svn qui sont
détecté par branchify. Si aucune des expressions ne correspond au comportement par défaut s'applique,
qui mappe une branche au nom du dernier répertoire, à l'exception de trunk et "*" qui
sont mappés sur master et root.

Sans arguments, les paires de remplacement de regex actuelles sont affichées. Passer « reset »
effacer le mappage de réinitialisation.

Correspondra à chaque nom de branche avec regex1 et s'il correspond, réécrira son nom de branche
à la branche1. Sinon, il essaiera regex2 et ainsi de suite jusqu'à ce qu'il trouve une correspondance
regex ou il n'y a plus de regex. Les expressions régulières doivent être dans Python[2].
format. Le nom de la branche peut utiliser des références arrière (voir la sous-fonction dans le Python
Documentation).

Notez que les expressions régulières sont ajoutées à 'refs/' sans les
'heads/' ou 'tags/'. Cela permet de choisir le bon type de type de branche.

Alors que le modèle de syntaxe ci-dessus utilise des barres obliques, tout premier caractère sera utilisé comme
délimiteur (et vous devrez en utiliser un autre dans le cas courant où les chemins
contenir des barres obliques).

Notez que l'ensemble branchify_map est une propriété de l'interpréteur de reposurgeon, pas de
n'importe quel référentiel individuel, et persistera à travers les lectures de fichiers de vidage Subversion. Ceci peut
conduire à des résultats inattendus si vous oubliez de le réinitialiser.

EXAMEN ARBRE ÉTATS
manifeste [Standard expression] [>fichier de sortie]
Prend un argument de jeu de sélection facultatif par défaut à tous les commits, et un argument facultatif
Expression régulière Python. Pour chaque commit dans le jeu de sélection, imprimez le mappage de
tous les chemins de cet arbre de validation vers les marques de blob correspondantes, en reflétant les fichiers
serait créé dans une extraction du commit. Si une expression régulière est donnée, seule
imprime les lignes "chemin -> marque" pour les chemins qui lui correspondent. Cette commande prend en charge > la redirection.

caisse annuaire
Prend un jeu de sélection qui doit se résoudre en un seul commit et un deuxième argument.
Le deuxième argument est interprété comme un nom de répertoire. L'état de l'arbre de code à
ce commit est matérialisé sous le répertoire.

diff [>fichier de sortie]
Affichez la différence entre les commits. Prend un argument de jeu de sélection qui doit
résoudre exactement deux commits. Prend en charge la redirection de sortie.

ENTRETIEN MÉNAGER
Celles-ci sont sauvegardées par les commandes d'entretien suivantes, dont aucune ne prend une sélection
ensemble:

vous aider
Obtenez de l'aide sur les commandes de l'interpréteur. Faites suivre éventuellement d'un espace et d'une commande
Nom; sans argument, répertorie toutes les commandes. '?' l'invoque également.

coquille
Exécutez la commande shell donnée dans le reste de la ligne. '!' l'invoque également.

préfère [repotyper]
Sans arguments, décrivez les capacités de tous les systèmes pris en charge. Avec un argument
(qui doit être le nom d'un système supporté) cela a deux effets :

Premièrement, s'il existe plusieurs référentiels dans un répertoire sur lequel vous effectuez une lecture,
lira celui qu'il préfère (sinon il se plaindra de ne pas pouvoir choisir parmi
leur).

Deuxièmement, cela changera le type de sortie préféré du rééducateur. Cela signifie que
vous faites une écriture dans un répertoire, il construira un référentiel du type préféré plutôt que
son type d'origine (s'il en avait un).

Si aucun type préféré n'a été explicitement sélectionné, la lecture dans un référentiel (mais pas un
flux d'importation rapide) définira implicitement le type préféré sur le type de ce
dépôt.

Dans les anciennes versions de reposurgeon, cette commande modifiait le type du
référentiel, s'il y en a un. Ce comportement interagissait mal avec les tentatives d'interprétation
identifiants hérités et a été supprimé.

Type de Source [repotyper]
Rapport (sans arguments) ou sélectionnez (avec un argument) le référentiel actuel
Type de Source. Ce type est normalement défini au moment de la lecture du référentiel, mais peut rester non défini
si la source était un fichier de flux.

Le type de source affecte l'interprétation des identifiants hérités (aux fins du =N
ensemble de visibilité et la commande 'références') en contrôlant les expressions régulières
utilisé pour les reconnaître. Si aucun type de sortie préféré n'a été défini, il peut également changer
le format de sortie des fichiers de flux créés à partir du référentiel.

Le type de source est défini de manière fiable chaque fois qu'un référentiel en direct est lu ou lorsqu'un
Le flux Subversion ou Fossil dump est interprété mais pas nécessairement par un autre flux
des dossiers. Flux générés par cvs-export-rapide(1) en utilisant le --reposurgeon sont détectés comme
CVS. Dans certains autres cas, le système source est détecté à partir de la présence de magie
$-headers dans les blobs de contenu.

INSTRUMENTATION
Quelques commandes ont été implémentées principalement pour le débogage et les tests de régression
mais peut être utile dans des circonstances inhabituelles.

La sortie de la plupart de ces commandes peut être redirigée individuellement vers une sortie nommée
déposer. Lorsque cela est indiqué dans la syntaxe, vous pouvez préfixer le nom du fichier de sortie avec « > » et donner
comme argument suivant.

indice [>fichier de sortie]
Afficher quatre colonnes d'informations sur les objets du jeu de sélection : leur nombre, leur
type, la note associée (ou '-' si aucune note) et un champ récapitulatif variant selon le type. Pour
une branche ou un tag c'est la référence ; pour un commit, c'est la branche commit ; pour une goutte
c'est le chemin du référentiel du fichier dans le blob.

La sélection par défaut définie pour cette commande est =CTRU, tous les objets sauf les blobs.

résoudre [étiquette-texte...]
Ne fait que résoudre une expression de jeu de sélection et faire écho au résultat
numéro d'événement défini sur la sortie standard. Le reste de la ligne après la commande est
utilisé comme étiquette pour la sortie.

Implémenté principalement pour les tests de régression, mais peut être utile pour explorer les
langue définie par la sélection.

assigner [prénom]
Calculez un jeu de sélection de premier plan et attribuez-lui un nom symbolique. C'est une erreur de
attribuer à un nom déjà attribué ou à tout nom de succursale existant. Devoirs
peut être éliminé par des mutations de séquence (mais pas par des délétions ordinaires) ; vous verrez un
avertissement lorsque cela se produit.

Sans jeu de sélection ni nom, répertoriez toutes les affectations.>

Utilisez-le pour optimiser les calculs de localisation et de sélection qui seraient autrement
effectué à plusieurs reprises, par exemple dans les appels de macro.

désaffecter [prénom]
Annuler l'attribution d'un nom symbolique. Lève une erreur si le nom n'est pas attribué.

noms [>fichier de sortie]
Répertoriez les noms de toutes les branches et balises connues. Vous indique ce qui est légal à l'intérieur
crochets angulaires et parenthèses.

verbeux [n]
'verbose 1' active la jauge de progression et les messages, 'verbose 0' les désactive. Plus haut
les niveaux de verbosité sont disponibles mais destinés uniquement aux développeurs.

calme [on | de rabais]
Sans argument, cette commande demande un rapport du booléen tranquille ; avec le
argument 'on' ou 'off' il est changé. Lorsque le silence est activé, les champs de rapport varient dans le temps
qui, autrement, provoqueraient de fausses défaillances dans les tests de régression sont supprimées.

impression texte-sortie...
Ne fait rien d'autre que d'envoyer sa ligne d'argument à la sortie standard. Utile en régression
Des tests.

echo [nombre]
'écho 1' provoque chacun repurger commande à renvoyer sur la sortie standard juste avant
sa sortie. Cela peut être utile pour construire des tests de régression qui sont facilement
vérifié par le globe oculaire.

scénario nom de fichier [arg...]
Prend un nom de fichier et les arguments suivants facultatifs. Lit chaque ligne du fichier et
l'exécute comme une commande.

Lors de l'exécution du script, le nom du script remplace la chaîne $0 et le
les arguments suivants facultatifs (le cas échéant) remplacent les chaînes $1, $2 ... $n dans le script
texte. Ceci est fait avant la tokenisation, donc le $1 dans une chaîne comme "foo$1bar" sera
étendu. De plus, $$ est étendu à l'ID de processus actuel (ce qui peut être utile
pour les scripts qui utilisent des fichiers temporaires).

Dans les scripts (et uniquement dans les scripts) repurger accepte un peu étendu
syntaxe : Tout d'abord, une barre oblique inverse terminant une ligne signale que la commande continue sur le
ligne suivante. N'importe quel nombre de lignes consécutives ainsi échappées sont concaténées, sans le
mettant fin aux barres obliques inverses, avant l'évaluation. Deuxièmement, une commande qui prend une entrée
l'argument de nom de fichier peut à la place prendre les données suivantes littérales dans la syntaxe d'un shell
ici-document. C'est-à-dire : si le nom du fichier est remplacé par "<
le script jusqu'à une ligne de terminaison composée uniquement de "EOF" sera lu, placé dans un
fichier temporaire, et ce fichier a été envoyé à la commande et ensuite supprimé. EOF peut être
remplacé par n'importe quelle chaîne. Les barres obliques inverses n'ont pas de signification particulière lors de la lecture d'un
ici-document.

Les scripts peuvent avoir des commentaires. Toute ligne commençant par un '#' est ignorée. Si une ligne a un
position de fin qui commence par un ou plusieurs caractères d'espacement suivis de '#',
cette partie de fin est ignorée.

version [version...]
Sans argument, affiche directement la version du programme et la liste des VCS
prise en charge. Avec argument, déclarez la version majeure (un seul chiffre) ou la version complète
(majeur.mineur) sous lequel le script englobant a été développé. Le programme fera une erreur
si la version majeure a changé (ce qui signifie que le langage chirurgical n'est pas
rétrocompatible).

Il est recommandé de démarrer votre script lift avec une exigence de version, en particulier
si vous allez l'archiver pour référence ultérieure.

prompt [le format...]
Définissez le format d'invite de commande sur la valeur de la ligne de commande ; avec une commande vide
ligne, affichez-la. Le format d'invite est évalué en Python après chaque commande avec le
substitutions de dictionnaire suivantes :

choisi
Le nom du référentiel sélectionné, ou Aucun si aucun n'est actuellement sélectionné.

Ainsi, un format utile pourrait être 'rs[%(chosen)s]%% '.

D'autres éléments de format peuvent être ajoutés à l'avenir. L'invite par défaut correspond à la
format 'reposurgeon%%'. La ligne de format est évaluée avec des citations de shell de jetons, donc
que des espaces peuvent être inclus.

Histoire
Répertoriez les commandes que vous avez entrées dans cette session.

héritage [lire|écrire] [<nom de fichier] [>nom de fichier]
Appliquez ou répertoriez les informations de référence héritées. Ne prend pas de jeu de sélection. La 'lire'
la variante lit à partir de l'entrée standard ou d'un nom de fichier <-redirected ; la variante « écrire »
écrit sur la sortie standard ou sur un nom de fichier redirigé >.

Un fichier de référence hérité mappe les cookies de référence à (committer, commit-date,
paires numéro de séquence) ; ceux-ci à leur tour (devraient) identifier de manière unique un commit. Le format
correspond à deux champs séparés par des espaces : le cookie suivi d'un tampon d'action identifiant
le commit.

Il ne devrait normalement pas être nécessaire d'utiliser cette commande. La carte héritée est
automatiquement préservé par les lectures et les reconstructions du référentiel, étant stocké dans le
fichier legacy-map dans le sous-répertoire du référentiel.

set [option]
Activez un indicateur d'option. Sans arguments, liste toutes les options

La plupart des options sont décrites conjointement avec les opérations spécifiques que le
modifier. L'un d'entre eux est d'intérêt général : les « compressblobs » ; cela permet une compression sur le
fichiers blob dans la représentation interne utilisée par reposurgeon pour éditer les référentiels.
Avec cette option, la lecture et l'écriture des référentiels sont plus lentes, mais l'édition d'un
Le référentiel nécessite moins (parfois beaucoup moins) d'espace disque.

clair [option]
Désactivez un indicateur d'option. Sans arguments, liste toutes les options

profil
Activer le profilage. Les statistiques de profil sont transférées vers le chemin donné en argument. Doit être
l'un des arguments initiaux de la ligne de commande et rassemble des statistiques uniquement sur le code
exécuté via '-'.

timing
Affichez les statistiques sur la synchronisation des phases dans l'analyse du référentiel. Principalement d'intérêt pour
développeurs essayant d'accélérer le programme.

sortie
Sortie, rapportant l'heure. Inclus ici parce que, tandis que EOT quittera également proprement le
interpréteur, cette commande rapporte le temps écoulé depuis le démarrage.

TRAVAIL avec SUBVERSION

reposurgeon peut lire les dumpfiles Subversion ou éditer un dépôt Subversion (et vous devez
pointez-le vers un référentiel, pas un répertoire de retrait). La distribution de reposurgeon comprend
un script nommé "repotool" que vous pouvez utiliser pour créer puis mettre à jour de manière incrémentielle un fichier local
miroir d'un référentiel distant à des fins d'édition ou de conversion.

LECTURE SUBVERSION REPOSITOIRES
Certains modificateurs optionnels de la commande read changent son comportement lors de la lecture de Subversion
référentiels :

--nobranche
Supprimer l'analyse de branche.

--ignore-propriétés
Supprimer les avertissements de temps de lecture concernant les paramètres de propriété ignorés.

--user-ignore
Ne générez pas de fichiers .gitignore à partir des propriétés svn:ignore. Au lieu de cela, il suffit de traverser
.gitignore fichiers trouvés dans l'historique.

--use-uuid
Si l'option de lecture --use-uuid est définie, l'UUID du référentiel sera utilisé comme
nom d'hôte lors de la falsification d'adresses e-mail, à la git-svn. Sinon, les adresses seront
généré de la manière dont git cvs-import le fait, en copiant simplement le nom d'utilisateur dans le
champ d'adresse.

Ces modificateurs peuvent aller n'importe où dans n'importe quel ordre sur la ligne de commande read après le verbe read.
Ils doivent être séparés par des espaces.

Voici les règles utilisées pour mapper les sous-répertoires d'un référentiel Subversion vers les branches :

1. À tout moment, il existe un ensemble de chemins éligibles et de caractères génériques de chemin qui déclarent
succursales potentielles. Voir la documentation du se brancher pour savoir comment modifier cet ensemble,
qui se compose initialement de {trunk, tags/*, branches/* et '*'}.

2. Un référentiel est considéré comme "plat" s'il n'a pas de répertoire correspondant à un chemin ou un chemin
joker dans l'ensemble branchify. Tous les commits dans un référentiel plat sont affectés à la branche
master, et ce qui aurait été une structure de branche devient une structure de répertoire. Dans ce
cas, nous avons terminé ; toutes les autres règles s'appliquent aux pensions non-flat.

Si vous donnez l'option --nobranche lors de la lecture d'un dépôt Subversion, branchez
l'analyse est ignorée et le référentiel est traité comme s'il était plat (à gauche comme un
séquence de commits sur refs/heads/master). Cela peut être utile si votre référentiel
la configuration est très inhabituelle et vous devez faire votre propre chirurgie de branche. Noter que
cette option désactivera le partitionnement des commits mixtes.

3. Si "trunk" est éligible, il devient toujours la branche master.

4. Si un élément de l'ensemble branchify se termine par *, chaque sous-répertoire immédiat de celui-ci est
considéré comme une branche potentielle. Si '*' est dans l'ensemble branchify (ce qui est vrai par
par défaut) tous les répertoires de niveau supérieur autres que /trunk, /tags et /branches sont également
considérés comme des branches potentielles.

5. Chaque branche potentielle est vérifiée pour voir si elle a des commits après la première
création ou copie. S'il y a de tels commits, cela devient une branche. Sinon, cela devient un
tag afin de préserver les métadonnées de commit. (Dans tous les cas, le nom de la balise ou
branche est le nom de base du répertoire.)

6. Les fichiers du répertoire de niveau supérieur sont affectés à une branche synthétique nommée 'root'.

Chaque commit qui crée ou supprime uniquement des répertoires (en particulier, copier les commits pour les balises
et les branches, et les commits qui ne changent que les propriétés) seront transformés en une balise
nommé d'après la branche, contenant les métadonnées date/auteur/commentaire du commit. Tandis que
cela produit un résultat souhaitable pour les balises, les branches sans balise (y compris le tronc) seront également
obtenir les balises racine de cette façon. Ce défaut apparent a été accepté de sorte que le repurge
ne détruira jamais les métadonnées générées par l'homme qui pourraient avoir de la valeur ; il est laissé au
l'utilisateur de supprimer manuellement les balises indésirables.

Les suppressions de branches Subversion sont transformées en deletealls, effaçant l'ensemble de fichiers du
branche import-stream. Lorsqu'une branche se termine avec un deleteall à son extrémité, le deleteall est
transformé en balise. Cette règle est nettoyée après un changement de nom de branche abandonné.

Occasionnellement (et généralement par erreur) un dépôt Subversion branché contiendra
révisions qui touchent plusieurs branches. Ceux-ci sont traités en les partitionnant en
plusieurs commits de flux d'importation, un sur chaque branche affectée. Le Legacy-ID d'une telle scission
commit aura une partie pseudo-décimale - par exemple, si la révision de Subversion 2317 touche
trois branches, les trois commits générés auront les ID 2317.1, 2317.2 et 2317.3.

Les propriétés svn:executable et svn:special sont traduites en paramètres d'autorisation dans
le flux d'entrée ; svn:executable devient 100755 et svn:special devient 120000 (indiquant
un lien symbolique ; le contenu du blob sera le chemin vers lequel le lien symbolique doit être résolu).

Toutes les propriétés cvs2svn:rev générées par cvs2svn sont incorporées dans la carte interne
utilisé pour l'élévation de référence, puis jeté.

Normalement, les propriétés svn:ignore par répertoire deviennent des fichiers .gitignore. Réel .gitignore
les fichiers dans un répertoire Subversion sont présumés avoir été créés par les utilisateurs de git-svn
séparément des propriétés Subversion natives ignorent et rejetées avec un avertissement. C'est au programme
à l'utilisateur de fusionner manuellement le contenu de ces fichiers dans le référentiel cible. Mais
ce comportement est inversé par l'option --user-ignores ; si c'est activé, les fichiers .gitignore
sont transmises et les propriétés Subversion svn:ignore sont ignorées.

(Quel que soit le paramètre de l'option --user-ignores, les fichiers .cvsignore trouvés dans
Les dépôts Subversion deviennent toujours des .gitignores dans la traduction. L'hypothèse est
que ceux-ci datent d'avant un ascenseur CVS-SVN et doivent être conservés pour affecter le comportement
lorsque vous parcourez cette section du référentiel.)

Les propriétés svn:mergeinfo sont interprétées. Toute propriété svn:mergeinfo sur une révision A avec
une plage de source de fusion se terminant par la révision B produit un lien de fusion tel que B devient un
parent d'A.

Toutes les autres propriétés de Subversion sont supprimées. (Cela peut changer dans une version future.) Le
La propriété pour laquelle cela est le plus susceptible de causer des problèmes sémantiques est svn:eol-style.
Cependant, étant donné que les commits de modification de propriété uniquement sont transformés en balises annotées, le
Les balises conserveront les informations sur les modifications apportées aux paramètres.

La résolution inférieure à la seconde sur les dates de validation de Subversion est ignorée ; Git veut un entier
horodatage uniquement.

Étant donné que le format d'importation rapide ne peut pas représenter un répertoire vide, les répertoires vides dans
Les dépôts Subversion seront perdus dans la traduction.

Normalement, les noms d'utilisateur locaux de Subversion sont mappés dans le style de git cvs-import ; donc utilisateur
"foo" devient "foo ", ce qui est suffisant pour pacifier git et d'autres systèmes qui
nécessitent des adresses e-mail. Avec l'option "svn_use_uuid", les noms d'utilisateur sont mappés dans le
style git-svn, avec l'UUID du référentiel utilisé comme faux domaine dans l'adresse e-mail. Les deux
les formulaires peuvent être remappés à l'adresse réelle en utilisant le auteurs lire commander.

La lecture d'un flux Subversion permet d'écrire la carte héritée en tant que passerelles « héritées »
lorsque le référentiel est écrit dans un fichier de flux.

repurger s'efforce de faire ce qu'il faut en silence, mais il existe des cas extrêmes de Subversion
dans lequel il émet des avertissements car un humain peut avoir besoin d'intervenir et d'effectuer des corrections en
main. Voici les messages les moins évidents qu'il peut émettre :

.gitignore généré par l'utilisateur
Ce message signifie signifie repurger a trouvé un fichier .gitignore dans Subversion
référentiel qu'il analyse. Cela s'est probablement produit parce que quelqu'un utilisait git-svn
en tant que passerelle en direct, et créé des ignores qui peuvent ou non être conformes à ceux de
les fichiers .gitignore générés que les propriétés d'ignorance de Subversion seront
traduit en. Vous devrez prendre une décision politique concernant l'ensemble d'ignorés à
utiliser dans la conversion, et éventuellement définir l'option --user-ignores en lecture pour passer
via des fichiers .gitignore créés par l'utilisateur ; dans ce cas, cet avertissement ne sera pas émis.

impossible de connecter la branche non vide XXXX à l'origine
C'est une erreur sérieuse. repurger n'a pas pu trouver un lien à partir d'un
branche vers la branche principale (maître). Le graphe de validation ne sera pas entièrement connecté et
aura besoin d'une réparation manuelle.

les informations d'autorisation peuvent être perdues
Un changement de nœud Subversion sur un fichier définit ou efface les propriétés, mais aucun ancêtre ne peut être
trouvé pour ce fichier. La position de l'exécutable ou du lien symbolique peut être mal définie plus tard
révisions de ce fichier. Les propriétés définies par l'utilisateur de Subversion peuvent également être cryptées ou
perdu. Cette erreur peut généralement être ignorée.

ensemble de propriétés
repurger a détecté un paramètre d'une propriété définie par l'utilisateur, ou le Subversion
propriétés svn:externals. Ces propriétés ne peuvent pas être exprimées dans un flux d'importation ;
l'utilisateur est averti au cas où il s'agirait d'un obstacle à la conversion ou à certains
une action corrective est requise, mais normalement cette erreur peut être ignorée. Cet avertissement est
supprimé par l'option --ignore-properties.

liens de branche détectés par les opérations de fichier uniquement
Les liens de branche sont normalement déduits en examinant les opérations de copie de répertoire Subversion. UNE
erreur utilisateur courante (créer une branche avec une copie de répertoire non Subversion, puis faire
un svn ajouter sur les combats) peut vaincre cela. Tandis que repurger devrait détecter et faire face
avec la plupart de ces copies correctement, vous devriez examiner le graphe de validation pour vérifier que le
branche est enracinée au bon endroit.

impossible de baliser le commit racine
Le premier commit dans votre référentiel Subversion a des opérations sur les fichiers, plutôt que
étant une pure création de répertoire. Cela signifie probablement que votre fichier de vidage Subversion est
mal formé, ou vous avez peut-être tenté de le soulever à partir d'un vidage incrémentiel. Procéder à
mise en garde.

suppression de l'astuce sans parent supprimer
Ce message peut être déclenché par un déplacement de branche Subversion suivi d'une recréation
sous le nom de la source. Vérifiez près de la révision indiquée pour vous assurer que la version renommée
la branche est connectée au maître.

supprimer tout en milieu de branche
Une opération deleteall a été trouvée au milieu d'un historique de branche. Cela généralement
indique qu'une balise ou une branche Subversion a été créée par erreur, et que quelqu'un plus tard
essayé d'annuler l'erreur en supprimant le répertoire tag/branch avant de le recréer avec
une opération de copie. Examinez de près la topologie près du deleteall, il peut être nécessaire
piratage à la main. Il est assez probable que (a) le repurger la traduction sera
différent de ce que d'autres traducteurs (comme git-svn) produire, et (b) il ne
être immédiatement évident qui est juste.

impossible de trouver une racine de branche pour la copie
L'analyse de branche a échoué, probablement en raison d'un ensemble de copies de fichiers qui repurger pensée
il devrait interpréter comme une création de branche bâclée mais ne pourrait pas en déduire un historique.
Utilisez l'option --nobranch.

vide de manière incohérente de l'ensemble
Ce message signifie signifie repurger a échoué à un contrôle de cohérence interne ; les
la structure de répertoires impliquée par ses mappes de fichiers construits en interne n'est pas cohérente avec
ce qu'il y a dans les nœuds Subversion analysés. Cela ne devrait jamais arriver ; si vous le voyez, signalez
un bug dans repurger.

L'ÉCRITURE SUBVERSION REPOSITOIRES
reposurgeon prend en charge l'écriture de référentiels Subversion. En raison de discordances entre les
ontologie de Subversion et celle des flux d'import git, ce support a des
limites et bogues.

En résumé, les historiques des référentiels Subversion ne passent pas par l'édition de reposurgeon.
Les modifications du contenu des fichiers sont conservées mais certaines métadonnées sont inévitablement perdues. Par ailleurs,
écrire un historique DVCS dans Subversion perd également des portions importantes de ses métadonnées.
Les détails suivent.

L'écriture d'un dépôt ou d'un flux de vidage Subversion supprime les informations sur l'auteur, le
le nom du commiter et la partie hostname de l'adresse de commit ; seulement l'horodatage du commit
et la partie locale de l'adresse e-mail de l'auteur sont conservées, cette dernière devenant la
Champ auteur Subversion. Cependant, lire un dépôt Subversion et le réécrire
conservera les champs auteur.

Les horodatages de flux d'importation ont une granularité d'une seconde. Les sous-secondes parties de Subversion
les horodatages des commits seront perdus au cours de leur cheminement vers le re-chirurgien.

Les répertoires vides ne sont pas représentés dans les flux d'importation. Par conséquent, la lecture et l'écriture
Les référentiels Subversion préservent le contenu des fichiers, mais pas les répertoires vides. Ce n'est pas non plus
garanti qu'après l'édition d'un référentiel Subversion que la séquence de répertoire
les créations et suppressions relatives aux autres opérations seront identiques ; la seule garantie
est que les répertoires englobants seront créés avant les fichiers qu'ils contiennent.

Lors de la lecture d'un dépôt Subversion, le reposurgeon rejette la copie de répertoire spéciale
nœuds associés aux créations de branches. Ceux-ci ne peuvent pas être recréés si et quand le
le référentiel est réécrit dans Subversion ; au lieu de cela, chaque nœud de copie de branche du
l'original se traduit par une création de branche plus le premier ensemble de modifications de fichiers sur le
branche.

Lors de la lecture d'un dépôt Subversion, le reposurgeon se sépare également automatiquement
commits à branches mixtes. Ceux-ci ne sont pas réunis si le référentiel est réécrit.

Lors de l'écriture dans un référentiel Subversion, toutes les balises légères deviennent des copies de balises Subversion
avec des commentaires de journal vides, nommés pour le nom de base de la balise. Le nom et l'horodatage du commiteur sont
copié à partir du commit sur lequel pointe la balise. La distinction entre les têtes et les balises est perdue.

En raison des deux points précédents, il n'est pas garanti que même les numéros de révision
être stable lorsqu'un dépôt Subversion est lu puis écrit !

Les dépôts Subversion sont toujours écrits avec une disposition standard (tronc/balises/branches).
Ainsi, un référentiel de forme non standard qui a été analysé par le rechirurgien ne sera pas
écrit avec la même forme.

Lors de l'écriture d'un référentiel Subversion, les fusions de branches sont traduites en svn:mergeinfo
propriétés de la manière la plus simple possible - en tant que propriété svn:mergeinfo du fichier traduit
merge commit répertoriant les révisions de la source de fusion.

Subversion a un concept de "flux" ; c'est-à-dire des segments nommés de l'histoire correspondant à
fichiers ou répertoires créés lorsque le chemin est ajouté, clonés lorsque le chemin est
copié et supprimé lorsque le chemin est supprimé. Ces informations ne sont pas conservées lors de l'import
les cours d'eau ou la représentation interne qu'utilise le repurgeur. Ainsi, après édition, le
Les limites de flux d'un historique Subversion peuvent être arbitrairement modifiées.

IGNORER MOTIFS

repurger reconnaît comment les VCS pris en charge représentent les fichiers ignorés (fichiers CVS .cvsignore
caché non traduit dans les anciens dépôts Subversion, Subversion ignore les propriétés,
.gitignore/.hgignore/.bzrignore fichier dans d'autres systèmes) et déplace les déclarations d'ignorer parmi
ces conteneurs sur l'entrée et la sortie du référentiel. Ce sera suffisant si les modèles ignorer
sont des noms de fichiers exacts.

La traduction peut cependant ne pas être parfaite lorsque les motifs ignorés sont des motifs glob Unix
ou des expressions régulières. Ce tableau de compatibilité décrit les modèles qui seront traduits ;
« plain » indique un nom de fichier brut sans syntaxe ou négation glob ou regexp.

RCS n'a pas de fichiers ou de modèles ignorés et n'est donc pas inclus dans le tableau.

?? ?? ??
│ grâce au CVS │ grâce au svn │ grâce au jet │ grâce au hg │ grâce au bzr │ grâce au darcs │ grâce au SRC │
?? ?? ??
│ à │ tous │ tous │ tous │ tous │ tous │ clair │ tous │
│ CVS │ │ │ sauf │ │ sauf │ │ │
?? ?? ??
│ à │ !.PP │ tous │ tous sauf │ tous │ tous sauf │ clair │ tous │
│ svn │ │ │ !-préfixé │ │ RE:- et │ │ │
?? ?? ??
│ à │ tous │ tous │ tous │ tous │ tous sauf │ clair │ tous │
│ jet │ │ │ │ sauf │ RE:-préfixé │ │ │
?? ?? ??
│ à │ tous │ tous │ tous sauf │ tous │ tous sauf │ clair │ tous │
│ hg │ sauf │ │ !-préfixé │ │ RE:- et │ │ │
?? ?? ??
│ à │ tous │ tous │ tous │ tous │ tous │ clair │ tous │
│ bzr │ │ │ │ │ │ │
?? ?? ??
│ à │ uni │ uni │ uni │ uni │ uni │ tous │ tous │
│ darcs │ │ │ │ │ │ │
?? ?? ??
│ à │ tous │ tous │ tous sauf │ tous │ tous sauf │ clair │ tous │
│ SRC │ sauf │ │ !-préfixé │ │ RE:- et │ │ │
?? ?? ??

Les lignes et colonnes hg du tableau décrivent la compatibilité avec la syntaxe glob de hg plutôt
que sa syntaxe d'expression régulière par défaut. Lors de l'écriture dans un référentiel hg à partir de n'importe quel
autre genre, repurger ajoute à la sortie .hgignore une ligne "syntaxe: glob".

TRADUCTION STYLE

Après avoir converti un référentiel CVS ou SVN, recherchez et supprimez les $-cookies dans la tête
révision(s) des fichiers. L'ensemble complet de Subversion est $Date :, $Revision :, $Author :,
$HeadURL et $Id :. CVS utilise $Author :, $Date :, $Header :, $Id :, $Log :, $Revision :, également
(rarement) $Locker :, $Name :, $RCSfile :, $Source : et $State :.

Lorsque vous devez spécifier un commit, utilisez le format action-stamp qui .
génère lorsqu'il peut résoudre une référence SVN ou CVS dans un commentaire. Il est préférable que vous
pas varier grâce au ceci. le format, même de manière triviale comme omettre le « Z » ou changer le « T »
ou '!' ou ':'. Rendre les tampons d'action uniformes et analysables par machine aura de bons
conséquences pour les futurs outils de navigation dans les référentiels.

Parfois, lors de la conversion d'un référentiel, vous devrez peut-être insérer un commentaire explicatif - pour
exemple, si les métadonnées ont été brouillées ou manquantes et que vous devez le signaler. C'est
utile pour les outils de navigation dans les référentiels s'il existe une syntaxe uniforme pour cela qui est hautement
peu probable d'apparaître dans les commentaires du référentiel. Nous vous recommandons de joindre les notes de traduction dans [[
]]. Cela a l'avantage d'être visuellement similaire au [ ] traditionnellement utilisé pour
commentaires éditoriaux dans le texte.

Il est recommandé d'inclure, dans le commentaire du commit racine du référentiel, un
noter la datation et l'attribution des travaux de conversion et l'explication de ces conventions. Exemple:

[[Ce référentiel a été converti de Subversion en git le 2011-10-24 par Eric S. Raymond
<[email protected]>. Ici et ailleurs, les notes de conversion sont enfermées dans un double carré
supports. Les commits indésirables générés par cvs2svn ont été supprimés, les références de commit ont été
mappé dans une syntaxe uniforme indépendante du VCS, et certains commentaires édités dans
formulaire résumé-plus-suite.]]

Il est également recommandé d'inclure une balise générée au moment de la conversion. Par exemple

box_in --create <
Nom de la balise : git-conversion

Marque l'endroit où ce dépôt a été converti de Subversion en git.
EOF

Avancé EXEMPLES

définir le dernier changement {
@max(=B & [/ChangeLog/] & /{0}/B) ? liste
}

Répertoriez le dernier commit qui fait référence à un fichier ChangeLog contenant une chaîne spécifiée. (Les
astuce c'est ça ? étend l'ensemble singleton composé du dernier ChangeLog éligible
blob à son ensemble de commits référents, et listene remarque que les commits.)

FLUX SYNTAXE EXTENSIONS

L'analyseur de flux d'événements dans « reposurgeon » prend en charge une syntaxe étendue. Exportateurs conçus
travailler avec « reposurgeon » peut avoir une option --reposurgeon qui permet l'émission de
syntaxe étendue ; c'est notamment le cas de cvs-export-rapide(1). Le reste de cette
La section décrit ces extensions de syntaxe. Les propriétés qu'ils définissent sont (généralement) préservées
et re-sortie lorsque le fichier de flux est écrit.

Le jeton « #reposurgeon » au début d'une ligne de commentaire dans un flux d'importation rapide signale
reposurgeon que le reste est une commande d'extension à interpréter par « reposurgeon ».

Une telle commande d'extension est implémentée : #Type de Source, qui se comporte de manière identique au
repurgerType de Source commander. Un exportateur pour un système de contrôle de version nommé « frobozz »
pourrait, par exemple, dire

#reposurgeon sourcetype frobozz

Dans un commit, un commentaire magique de la forme « #legacy-id » déclare un identifiant hérité du
système de contrôle de version source du fichier stream.

La syntaxe bzr pour définir les propriétés par commit est également acceptée. Lors de l'analyse de commit
syntaxe, une ligne commençant par le jeton « property » doit se poursuivre par un
jeton de nom de propriété séparé par des espaces. S'il est suivi d'une nouvelle ligne, il est pris
pour définir cette propriété booléenne sur true. Sinon, il doit être suivi d'un chiffre
jeton spécifiant une longueur de données, un espace, les données suivantes (qui peuvent contenir des sauts de ligne) et un
fin de nouvelle ligne. Par exemple:

valider les références/heads/master
note : 1
le commissaire Eric S. Raymond[email protected]> 1289147634 -0500
Date 16
Exemple de commit.

propriété legacy-id 2 r1
M 644 en ligne README

Contrairement à d'autres extensions, les propriétés bzr ne sont conservées sur la sortie du flux que si le
le type préféré est bzr, car tout importateur autre que bzr s'étouffera avec eux.

INCOMPATIBLE LANGUAGE CHANGEMENTS

Dans les versions antérieures à 3.0, la syntaxe de commande générale mettait le verbe de commande en premier, puis le
jeu de sélection (le cas échéant) puis modificateurs (VSO). Il est devenu un jeu de sélection facultatif
d'abord, puis le verbe de commande, puis les modificateurs (SVO). Le changement a rendu l'analyse plus simple, a permis
abolissant certains mots-clés de bruit, et récapitule un modèle de conception réussi dans certains
d'autres outils Unix - notamment sed (1).

Dans les versions antérieures à 3.0, les expressions de chemin ne correspondaient qu'aux commits, pas aux commits et le
blobs associés aussi. Les noms des drapeaux « a » et « c » étaient différents.

In repurger versions antérieures à 3.0, la commande delete avait la sémantique de squash ; aussi,
les indicateurs de stratégie ne nécessitaient pas de préfixe « - ». Le drapeau "--delete" a été nommé
"effacer".

In repurger versions antérieures à 3.0, la lecture et l'écriture ont éventuellement pris des arguments de fichier plutôt
que d'exiger des redirections (et la commande d'écriture n'a jamais écrit dans des répertoires). C'était
modifié afin de permettre à ces commandes d'avoir des modificateurs. Ces modificateurs ont remplacé
plusieurs options globales qui n'existent plus.

In repurger versions antérieures à 3.0, le facteur le plus ancien dans une commande unit a toujours conservé son
les noms des balises et des branches restent inchangés. La nouvelle règle de résolution des conflits de noms, en privilégiant
au dernier facteur, produit un comportement plus naturel lors de l'union de deux référentiels
finir; la branche master de la seconde (plus tardive) garde son nom.

In repurger versions antérieures à la 3.0, la commande tagify attendait des politiques en fin de chaîne
arguments pour modifier son comportement. La nouvelle syntaxe utilise des options de même nom avec en tête
tirets, qui peuvent apparaître n'importe où après la commande tagify

Dans les versions antérieures à la 2.9. la syntaxe de "authors", "legacy", "list" et "mailbox_{in|out}"
était différent (et « l'héritage » était « fossiles »). Ils ont pris des arguments de nom de fichier simples plutôt que
en utilisant la redirection < et >.

LIMITATIONS ET GARANTIES

Garantie : dans les DVC qui utilisent des hachages de validation, l'édition avec repurger ne change jamais le
hachage d'un objet commit sauf si (a) vous modifiez le commit, ou (b) s'il est un descendant d'un
commit édité dans un VCS qui inclut des hachages parent dans l'entrée du hachage d'un objet enfant
(git et hg le font tous les deux).

Garantie: repurger ne nécessite que de la mémoire principale proportionnelle à la taille d'un
l'historique des métadonnées du référentiel, et non l'intégralité de l'historique de son contenu. (Exception : les données de
le contenu en ligne est conservé en mémoire.)

Garantie : Dans le pire des cas, repurger fait sa propre copie de chaque blob de contenu dans le
l'historique du référentiel et utilise donc un espace disque intermédiaire approximativement égal à la taille
de l'historique du contenu d'un référentiel. Cependant, lorsque le référentiel à éditer est présenté
en tant que fichier de flux, repurger ne nécessite pas ou très peu d'espace disque supplémentaire pour
le représenter; la représentation interne des blobs de contenu est une paire (recherche-décalage, longueur)
pointant vers le fichier de flux.

Garantie: repurger ne modifie jamais le contenu d'un référentiel qu'il lit, ni ne le supprime
n'importe quel référentiel. Les résultats de la chirurgie sont toujours exprimés dans un nouveau référentiel.

Garantie : toute ligne dans un flux d'importation rapide qui ne fait pas partie d'une commande repurger
les analyses et les compréhensions seront transmises sans modification. À l'heure actuelle, l'ensemble des potentiels
les passthroughs sont connus pour inclure les le progrès, la Optionset point de contrôle commandes comme
ainsi que des commentaires dirigés par #.

Garantie : Tout repurger les opérations préservent tout l'état du référentiel, elles ne le sont pas
explicitement dit de modifier ou de vous avertir lorsqu'ils ne peuvent pas le faire.

Garantie: repurger gère l'extension bzr commit-properties, en passant correctement
via des éléments de propriété, y compris ceux avec des sauts de ligne intégrés. (Ces propriétés sont également
modifiable au format boîte aux lettres.)

Limite :                                                              repurger s'appuie sur d'autres programmes pour générer et interpréter les
flux de commandes d'importation rapide, il est sujet à des bogues dans ces programmes.

Limitation : bzr souffre d'une profonde confusion quant à savoir si son unité de travail est un référentiel
ou une branche flottante qui pourrait avoir été clonée à partir d'un dépôt ou créée à partir de zéro, et
pourrait ou non être destiné à être fusionné en un repo un jour. Son exportateur ne travaille que sur
branches, mais son importateur crée des repos. Ainsi, une opération de reconstruction produira un
structure de sous-répertoire qui diffère de ce que vous attendez. Recherchez votre contenu sous le
sous-répertoire « tronc ».

Limitation : sous git, les balises signées sont importées textuellement. Cependant, toute opération qui
modifie tout commit en amont de la cible du tag l'invalidera.

Limitation : Stock git (au moins à partir de la version 1.7.3.2) étouffera l'extension de propriété
commandes. Par conséquent, repurger les omet lors de la reconstruction d'un dépôt avec le type git.

Limitation : alors que le support côté lecture de Subversion est en bon état, le côté écriture
le support est plus une esquisse ou une preuve de concept qu'une mise en œuvre robuste ; il seulement
fonctionne sur des cas très simples et ne fait pas d'aller-retour. Cela pourrait s'améliorer dans les prochaines versions.

Limitation: repurger peut mal se comporter sous un système de fichiers qui casse la casse dans les noms de fichiers,
ou qui préserve nominalement la casse mais mappe les noms ne différant que par la casse au même
nœud du système de fichiers (Mac OS X se comporte ainsi par défaut). Des problèmes surgiront si deux
les chemins dans un référentiel diffèrent uniquement par cas. Pour éviter le problème sur un Mac, faites toutes vos opérations sur
un système de fichiers HFS+ formaté avec la sensibilité à la casse spécifiquement activée.

Garantie : à mesure que les systèmes de contrôle de version prennent en charge le format d'importation rapide, leur
les référentiels deviendront modifiables par repurger.

EXIGENCES

repurger s'appuie sur les importateurs et exportateurs associés aux VCS qu'il prend en charge.

jet
Core git prend en charge à la fois l'exportation et l'importation.

bzr
Nécessite bzr plus le plugin bzr-fast-import.

hg
Nécessite core hg, le plugin hg-fastimport et le tiers hg-fast-export.py
scripts.

svn
Les commandes Stock Subversion prennent en charge l'exportation et l'importation.

darcs
Les commandes Stock darcs prennent en charge l'exportation et l'importation.

CVS
Nécessite cvs-fast-export. Notez que la qualité des ascenseurs CVS peut être médiocre, avec
ascenseurs individuels nécessitant de sérieux piratages manuels. Cela est dû à des problèmes inhérents à
Le modèle orienté fichier de CVS.

RCS
Nécessite cvs-fast-export (oui, ce n'est pas une faute de frappe ; cvs-fast-export gère RCS
collections aussi). La mise en garde pour CVS s'applique.

CANONICALISATION DES RÈGLES

Il est prévu que repurger sera étendu avec plus de politiques de suppression. Politique
les auteurs peuvent avoir besoin d'en savoir plus sur la façon dont la séquence d'opérations de fichier d'un commit est réduite à
forme normale après que les opérations des commits supprimés y soient ajoutées.

Rappelez-vous que chaque commit a une liste d'opérations sur les fichiers, chacune un M (modifier), D (supprimer), R
(renommer), C (copier) ou 'deleteall' (supprimer tous les fichiers). Seules les opérations M ont associé
gouttes. Normalement, il n'y a qu'une seule opération M par fichier individuel dans une opération de validation
liste.

Pour comprendre comment fonctionne le processus de réduction, il suffit de comprendre le cas où
toutes les opérations de la liste fonctionnent sur le même fichier. Sous-listes d'opérations
faire référence à différents fichiers n'affecte pas les uns les autres et les réduire peut être pensé
en tant qu'opérations distinctes. De plus, un "deleteall" agit comme un D pour tout et annule tout
opérations avant lui dans la liste.

Le processus de réduction parcourt la liste depuis le début à la recherche de paires adjacentes
d'opérations qu'il peut composer. Le tableau suivant décrit tous les cas possibles et tous sauf
l'une des réductions.

?? ??
M + D → D │ │
│ │ Si un fichier est modifié │
│ │ puis supprimé, le résultat │
│ │ c'est comme si ça avait été │
│ │ supprimé. Si le M était le │
│ │ modifier uniquement pour le fichier, │
│ c'est supprimé aussi. ??
?? ??
M a + R ab → R ab + M b │ │
│ │ Le but de ceci │
│ la transformation c'est pousser │
│ │ renomme vers le │
│ │ début de la liste, │
│ │ où ils peuvent devenir │
│ │ adjacent à un autre R ou │
│ │ C ils peuvent être composés │
│ avec. Si le M est le │
│ │ ne modifier l'opération que pour │
│ │ ce fichier, le renommer est │
│ tombé. ??
?? ??
M a + C ab │ │
│ │ Pas de réduction. ??
?? ??
│ M b + R ab → rien │ │
│ │ Devrait être impossible, et │
│ │ peut indiquer le référentiel │
│ corruption. ??
?? ??
│ M b + C ab → rien │ │
│ │ La copie défait le │
│ modification. ??
?? ??
D + M → M │ │
│ │ Si un fichier est supprimé et │
│ │ modifié, le résultat est │
│ │ comme si la suppression │
│ │ n'avait pas eu lieu │
│ │ (car M opérations │
│ │ stocker des fichiers entiers, pas │
│ deltas). ??
?? ??
D + {D|R|C} │ │
│ │ Ces cas devraient être │
│ │ impossible et serait │
│ │ suggérer le référentiel │
│ │ a été corrompu. ??
?? ??
R ab + D a │ │
│ │ Ne devrait jamais arriver, et │
│ │ est un autre cas qui │
│ │ suggérerait un référentiel │
│ corruption. ??
?? ??
R ab + D b → D a │ │
│ │ La suppression supprime le │
│ │ vient de renommer le fichier. ??
?? ??
{R|C} + M │ │
│ │ Pas de réduction. ??
?? ??
R ab + R bc → R ac │ │
│ │ Les b termes doivent correspondre │
│ │ pour ces opérations à │
│ │ ont eu du sens quand ils │
│ │ vivait séparément │
│ │ s'engage ; s'ils ne le font pas,
│ │ il indique le référentiel │
│ corruption. ??
?? ??
R ab + C bc │ │
│ │ Pas de réduction. ??
?? ??
C ab + D a → R ab │ │
│ │ Copier suivi de supprimer │
│ │ de la source est un │
│ renommer. ??
?? ??
│ C ab + D b → rien │ │
│ │ Cette suppression annule le │
│ copie. ??
?? ??
C ab + R ac │ │
│ │ Pas de réduction. ??
?? ??
C ab + R bc → C ac │ │
│ │ Copier suivi d'un renommer │
│ │ de la cible se réduit à │
│ │ exemplaire unique │
?? ??
C + C │
│ │ Pas de réduction. ??
?? ??

CRASH RÉCUPÉRATION

Cette section ne deviendra pertinente que si repurger ou quelque chose en dessous dans le
la pile logicielle et matérielle se bloque pendant l'écriture d'un référentiel, dans
particulier si le répertoire cible de la reconstruction est votre répertoire courant.

L'outil a deux objectifs contradictoires. D'une part, nous ne voulons jamais risquer de tabasser
une pension préexistante. D'autre part, nous voulons pouvoir exécuter cet outil dans un répertoire
avec un repo et modifiez-le en place.

Nous résolvons ce dilemme en jouant à un jeu de monte à trois répertoires.

1. Tout d'abord, nous construisons le référentiel dans un répertoire intermédiaire fraîchement créé. Si votre cible
répertoire est nommé /path/to/foo, le répertoire intermédiaire sera un pair nommé
/chemin/vers/foo-stageNNNN, où NNNN est un cookie dérivé de repurgerID de processus de.

2. Nous créons ensuite un répertoire de sauvegarde vide. Ce répertoire sera nommé /chemin/vers/foo.~N~,
où N est incrémenté afin de ne pas entrer en conflit avec les répertoires de sauvegarde existants.
repurger ne supprime jamais, en aucun cas, un répertoire de sauvegarde.

Jusqu'à présent, toutes les opérations sont sûres ; le pire qui puisse arriver jusqu'à présent si le
processus est interrompu est que les répertoires de transfert et de sauvegarde sont laissés pour compte.

3. La région critique commence. Nous déplaçons d'abord tout ce qui se trouve dans le répertoire cible vers le
répertoire de sauvegarde.

4. Ensuite, nous déplaçons tout dans le répertoire intermédiaire vers la cible.

5. Nous terminons en restaurant les fichiers non suivis dans le répertoire cible à partir de la sauvegarde
annuaire. Cela met fin à la région critique.

Pendant la région critique, tous les signaux qui peuvent être ignorés sont ignorés.

ERREUR RETOURS

Renvoie 1 en cas d'erreur fatale, 0 sinon. En mode batch, toutes les erreurs sont fatales.

Utilisez le rechirurgien en ligne à l'aide des services onworks.net