aemv - En ligne dans le Cloud

PROGRAMME:

Nom

aegis move file - renommer un ou plusieurs fichiers dans le cadre d'un changement

SYNOPSIS

égide -MoVe_file [ option...] ancien-nom nouveau nom [ old1 new1 [ old2 new2 ] ]
égide -MoVe_file -Lister [ option...]
égide -MoVe_file -Aidez-moi

DESCRIPTION

La égide -MoVe_file La commande est utilisée pour copier un fichier dans un changement et changer son nom à
le même temps.

Les fichiers nommés seront copiés à partir de la ligne de base (ancien fichier) dans le développement
répertoire (nouveau fichier), et ajouté à la liste des fichiers dans le changement.

Avertissement : S'il y a déjà des fichiers dans le répertoire de développement de l'un ou l'autre ancien-nom or
le nouveau nom ils seront écrasés.

La ancien fichier dans le répertoire de développement contiendra 1 Ko de texte aléatoire. L'aléatoire
le texte est suffisamment révoltant pour que la plupart des compilateurs donnent des messages d'erreur, si le
fichier soit référencé accidentellement. Ceci est souvent très utile lors du déplacement de fichiers d'inclusion.

Vous pouvez renommer les répertoires. Tous les fichiers du ancien-nom l'arborescence des répertoires sera renommée
être en dessous du nouveau nom arborescence de répertoires.

Déposez votre dernière attestation Nom Interprétation
Le programme égide tentera de déterminer les noms de fichiers du projet à partir des noms de fichiers
donné sur la ligne de commande. Tous les noms de fichiers sont stockés dans les projets égide en tant que relatifs
à la racine de l'arborescence de répertoires de base. L'annuaire de développement et le
répertoire d'intégration sont des ombres de ce répertoire de base, et donc ces noms relatifs
postulez ici aussi. Les fichiers nommés sur la ligne de commande sont d'abord convertis en chemins absolus
si nécessaire. Ils sont ensuite comparés au chemin de référence, le répertoire de développement
chemin et le chemin du répertoire d'intégration, pour déterminer un nom relatif à la ligne de base. Il est
une erreur si le fichier nommé se trouve en dehors de l'une de ces arborescences de répertoires.

La -BAse_RElative L'option peut être utilisée pour que les noms de fichiers relatifs soient interprétés comme
par rapport au chemin de la ligne de base ; les noms de fichiers absolus seront toujours comparés aux différents
chemins afin de déterminer un nom relatif à la ligne de base.

La nom_fichier_relatif_préférence dans le fichier de configuration utilisateur peut être utilisé pour modifier
ce comportement par défaut. Voir aeuconf(5) pour plus d'informations.

Processus Côté Effets
Cette commande annulera tout enregistrement de build ou de test, car l'ajout d'un autre fichier
les invalide logiquement.

Lorsque les fichiers de modifications sont répertoriés (égide -Lister Modifier_Fichiers -Laconique) les nouveaux fichiers (Nouveau-
prénom) apparaîtra dans la liste et les fichiers supprimés (ancien-nom) Sera ne sauraient apparaissent dans le
liste laconique. De même, lorsque les fichiers de projet sont répertoriés avec une modification explicite
numéro (égide -Lister Fichiers_projet -Laconique -Changer N) aucun des fichiers de modification, y compris
les fichiers nouveaux et supprimés apparaîtront dans la liste succincte. Ces deux caractéristiques sont
très utile lorsque vous appelez aegis depuis un DMT pour générer la liste des fichiers source.

Notification
La nouvelle_commande_fichier ainsi que supprimer_fichier_commande dans le projet config fichier sont exécutés, s'ils sont définis.
La commande_fichier_projet est également exécuté, s'il est défini, et s'il y a eu une intégration
récemment. Voir aepconf(5) pour plus d'informations.

BLANC

Aegis vous fournit ce que l'on appelle souvent un « chemin d'accès » qui indique le développement
outils (compilateurs, systèmes de construction, etc) regardez d'abord dans le répertoire de développement, puis dans
la ligne de base de la branche, et ainsi de suite jusqu'à la ligne de base du tronc.

Le problème avec les chemins d'affichage est que pour supprimer des fichiers, vous avez besoin d'une sorte de
"whiteout" pour dire "arrête de chercher, ça a été supprimé".

Lorsque vous utilisez le aerm(1) ou aemv(1) commandes, cela signifie "ajouter des informations à ce changement
qui supprimera le fichier de la ligne de base lorsque ce changement sera intégré". C'est à dire tout en
le changement est dans le va développé état, le fichier n'est "supprimé" que dans le développement
répertoire - il est toujours présent dans la ligne de base et le sera jusqu'à ce que le changement soit
intégré avec succès.

Lorsque vous utilisez le aerm(1) ou aemv(1) commandes, Aegis créera un fichier 1K pour agir en tant que
voile blanc. Son contenu est plutôt moche, de sorte que si vous compilez ou incluez le "supprimé"
fichier accidentellement, vous obtenez une erreur fatale. Cela vous rappellera de supprimer les obsolètes
les références.

Lorsque le changement est intégré, le fichier supprimé est ne sauraient copié/lié de la ligne de base à
le répertoire d'intégration, et est ne sauraient copié à partir du répertoire de développement. À ceci
temps il est physiquement parti (pas de voile blanc). On suppose qu'en raison de l'erreur
induisant un voile blanc, toutes les anciennes références ont été trouvées et corrigées pendant que le changement était dans le
va développé Etat.

Déposez votre dernière attestation Manifestes
Lors de la génération de la liste des fichiers à compiler ou à lier, il est important que le fichier
manifeste être généré à partir d'informations connues d'Aegis, plutôt qu'à partir du système de fichiers.
C'est pour plusieurs raisons:

(a) Aegis sait exactement où se trouvent les fichiers (source), alors que tout le reste est
déduire les connaissances d'Aegis ; et

(b) la recherche dans le système de fichiers est difficile lorsque le chemin d'accès à la vue est plus long que 2 répertoires
(et la méthode de branchement d'Aegis peut le rendre arbitrairement long); et

(c) Les fichiers de whiteout, et tout ce qui reste "qui traîne", confondra n'importe quelle méthode
qui interroge le système de fichiers.

La façon la plus simple d'utiliser la connaissance des fichiers d'Aegis est d'utiliser quelque chose comme un awk(1) scénario
traitement des listes de fichiers Aegis. Par exemple, vous pouvez le faire avec faire(1) comme suit :
# générer le fichier manifest
manifest.make.inc : manifest.make.awk
( égide -l cf -ter ; égide -l pf -ter ) | \
awk -f manifest.make.awk > manifest.make.inc
# inclut maintenant le fichier manifest
inclure manifest.make.inc
Remarque : ce serait inefficace si vous le faisiez une fois par répertoire, mais il n'y a rien
vous empêchant d'écrire de nombreux devoirs dans le manifeste.make.inc fichier, tout en un
passer.

Il est possible de faire la même chose avec le générateur de rapports d'Aegis (voir air(1) pour plus
informations), mais cela est plus complexe que le awk(1) scénario. Cependant, avec le
informations "directement de la bouche du cheval" pour ainsi dire, cela peut aussi être beaucoup plus intelligent.

Ce fichier manifeste deviendrait obsolète sans verrouillage avec le fichier d'Aegis
commandes d'opérations. En utilisant le commande_fichier_projet ainsi que change_file_command domaines de
le projet config fichier (voir aepconf(5) pour plus d'informations), vous pouvez supprimer ce fichier
à des moments stratégiques.
/* s'exécute lorsque le manifeste du fichier de modifications est modifié */
change_file_command = "rm -f manifest.make.inc";
/* s'exécute lorsque le manifeste du fichier de projet est modifié */
project_file_command = "rm -f manifest.make.inc";
Le nouveau fichier manifest sera donc reconstruit lors du prochain aeb(1) commande.

Options ainsi que Préférences
Il y a un -Pas de WhiteOut option, qui peut être utilisée pour supprimer les fichiers blancs lorsque vous utilisez
le aermde Géographie (1) et avec la aemv(1) commandes. il y a un correspondant -Blanc option, qui est
généralement la valeur par défaut.

Il y a un whiteout_preference dans le fichier des préférences utilisateur (voir aeuconf(5) pour
plus d'informations) si vous souhaitez définir cette option de manière plus permanente.

Whiteout Déposez votre dernière attestation Gabarits
La modèle_blanc domaine du projet config fichier peut être utilisé pour produire la langue-
fichiers d'erreurs spécifiques. Si aucune entrée de modèle de whiteout ne correspond, un fichier de 1 Ko très laid sera
être produit - il devrait induire des erreurs de compilation pour à peu près n'importe quelle langue.

Si vous souhaitez un message d'erreur plus lisible, des entrées telles que
modèle_blanc =
[
{
motif = [ "*.[ch]" ];
body = "#error Ce fichier a été supprimé.";
}
];
peut être très efficace (cet exemple suppose gcc(1) est utilisé).

S'il est essentiel que aucune fichier whiteout soit produit, disons pour les fichiers source C, vous pouvez
utilisez un modèle de whiteout tel que
modèle_blanc =
[
{ motif = [ "*.c" ]; }
];
parce qu'un absent corps le sous-champ signifie ne générer aucun fichier blanc.

Vous pouvez avoir plus d'une entrée de modèle de blanc, mais notez que l'ordre des
les entrées sont importantes. La première entrée qui correspond sera utilisée.

Notification
En cas de réussite de cette commande, les notifications généralement effectuées par le
aerm(1), aenfde Géographie (1) et avec la aent(1) les commandes sont exécutées, le cas échéant. Ceux-ci incluent le
commande_fichier_projet, nouvelle_commande_fichier, nouvelle_commande_test ainsi que supprimer_fichier_commande des champs
du projet config déposer. Voir aepconf(5) pour plus d'informations.

OPTIONS

Les options suivantes sont comprises :

-Changer nombre
Cette option peut être utilisée pour spécifier un changement particulier dans un projet. Voir
égide(1) pour une description complète de cette option.

-Aidez-moi
Cette option peut être utilisée pour obtenir plus d'informations sur la façon d'utiliser le égide
.

-Lister
Cette option peut être utilisée pour obtenir une liste de sujets appropriés pour cette commande.
La liste peut être plus générale que prévu.

-Not_Logging
Cette option peut être utilisée pour désactiver l'enregistrement automatique de la sortie et des erreurs à
un fichier. Ceci est souvent utile lorsque plusieurs commandes aegis sont combinées dans un shell
scripts.

-Projet prénom
Cette option peut être utilisée pour sélectionner le projet d'intérêt. Quand non -Projet
l'option est spécifiée, le AEGIS_PROJET variable d'environnement est consultée. Si
qui n'existe pas, l'utilisateur $HOME/.aegisrc le fichier est examiné pour un défaut
domaine du projet (voir aeuconf(5) pour plus d'informations). Si cela n'existe pas,
lorsque l'utilisateur ne travaille que sur des modifications au sein d'un même projet, le projet
nom par défaut à ce projet. Sinon, c'est une erreur.

-Laconique
Cette option peut être utilisée pour que les annonces produisent le strict minimum de
informations. Il est généralement utile pour les scripts shell.

-Verbeux
Cette option peut être utilisée pour amener aegis à produire plus de sortie. Par défaut égide
ne produit une sortie que sur les erreurs. Lorsqu'il est utilisé avec le -Lister option cette option
provoque l'ajout d'en-têtes de colonnes.

-Attendez Cette option peut être utilisée pour exiger que les commandes Aegis attendent les verrous d'accès, si
ils ne peuvent pas être obtenus immédiatement. Par défaut à l'utilisateur lock_wait_preference
si non spécifié, voir aeuconf(5) pour plus d'informations.

-Non attends
Cette option peut être utilisée pour exiger que les commandes Aegis émettent une erreur fatale si l'accès
les serrures ne peuvent pas être obtenues immédiatement. Par défaut à l'utilisateur
lock_wait_preference si non spécifié, voir aeuconf(5) pour plus d'informations.

-Blanc
Cette option peut être utilisée pour demander que les fichiers supprimés soient remplacés par un « whiteout »
fichier dans le répertoire de développement. L'idée est que la compilation d'un tel fichier
entraîner une erreur fatale, afin que toutes les références puissent être trouvées. C'est
généralement la valeur par défaut.

-No_WhiteOut
Cette option peut être utilisée pour demander qu'aucun fichier « blanchiment » ne soit placé dans le
répertoire de développement.

Voir aussi égide(1) pour les options communes à toutes les commandes aegis.

Toutes les options peuvent être abrégées ; l'abréviation est documentée en lettres majuscules,
toutes les lettres minuscules et les traits de soulignement (_) sont facultatifs. Vous devez utiliser consécutivement
séquences de lettres facultatives.

Toutes les options sont insensibles à la casse, vous pouvez les saisir en majuscules ou en minuscules ou un
combinaison des deux, la casse n'a pas d'importance.

Par exemple : les arguments "-project, "-PROJ" et "-p" sont tous interprétés comme signifiant le
-Projet option. L'argument "-prj" ne sera pas compris, car consécutifs
les caractères facultatifs n'ont pas été fournis.

Les options et autres arguments de ligne de commande peuvent être mélangés arbitrairement sur la ligne de commande,
après les sélecteurs de fonction.

Les noms d'options longs GNU sont compris. Étant donné que tous les noms d'option pour égide sont longues,
cela signifie ignorer le "-" de début supplémentaire. Les "--option=Plus-value" la convention est aussi
compris.

RECOMMANDÉ ALIAS

L'alias recommandé pour cette commande est
csh% alias aemv 'aegis -mv \!* -v'
sh$ aemv(){aegis -mv "$@" -v}

LES ERREURS

C'est une erreur si le changement n'est pas dans le va développé Etat.
C'est une erreur si la modification n'est pas attribuée à l'utilisateur actuel.
C'est une erreur si l'un des fichiers est déjà dans la modification.

EXIT STATUT

La égide La commande se terminera avec un statut de 1 en cas d'erreur. Les égide la commande ne fera que
quitter avec un statut de 0 s'il n'y a pas d'erreurs.

ENVIRONNEMENT VARIABLES

See égide(1) pour une liste des variables d'environnement qui peuvent affecter cette commande. Voir
aepconf(5) pour le fichier de configuration du projet projet_spécifique champ pour savoir comment définir
variables d'environnement pour toutes les commandes exécutées par Aegis.

Utiliser aemv en ligne à l'aide des services onworks.net