aeipass - En ligne dans le Cloud

PROGRAMME:

Nom

aegis intégrer pass - passer un changement intégration

SYNOPSIS

égide -Intégrer_Pass [ option...]
égide -Intégrer_Pass -Lister [ option...]
égide -Intégrer_Pass -Aidez-moi

DESCRIPTION

La égide -Intégrer_Pass la commande est utilisée pour notifier aegis qu'un changement est passé
l'intégration. Le changement est avancé de la qui est des services état à la terminé
Etat. boxwid = 1 down box "être" "intégré" flèche " intégrer" ljust " passer" ljust
case "terminé"

Cette commande met à jour les historiques des fichiers, de sorte que les futurs aecp(1) les commandes peuvent extraire
versions de fichiers précédentes de l'historique, et de sorte que les futures aed(1) les commandes peuvent fusionner hors de
fichiers de dates. L'historique est mis à jour à l'aide du history_create_command et
history_put_command champs du fichier de configuration du projet (voir aepconf(5) pour plus
informations). La passe d'intégration avortera avec une erreur si l'un de ces historiques
les commandes devraient échouer, par exemple en manquant d'espace disque. Si cela devait arriver, le
le changement restera dans le qui est des services état, et le répertoire d'intégration est
inchangé.

Une fois l'historique mis à jour, le répertoire d'intégration est renommé en référence
répertoire et l'ancien répertoire de base est supprimé.

Une fois la passe d'intégration terminée, la modification n'est plus attribuée à l'utilisateur actuel.

Historique Outils modifier Documents officiels
De nombreux outils d'histoire (par exemple RCS et SCCS) peuvent modifier le contenu du fichier lorsqu'il est
engagé. Cela nécessite généralement l'utilisation de chaînes de « mots-clés » spécifiques, et il y a
généralement des options pour désactiver ce comportement, mais les utilisateurs familiarisés avec les outils de contrôle de version
(par opposition aux systèmes de gestion de configuration) utiliseront souvent ces fonctionnalités. Les
le problème est que si le commit modifie le fichier, le fichier source dans le référentiel n'est plus
correspond plus au fichier objet dans le référentiel. C'est à dire l'outil d'historique a compromis
l'intégrité référentielle du référentiel. Par défaut, une erreur fatale est émise si le
le fichier est modifié par l'enregistrement, mais cela peut être modifié en un avertissement ou même
complètement ignoré; voir le history_put_trashes_file domaine de l' aepconf(5) pour plus
</br>L’Information.

Fichier Modification Horaires
Les heures de modification de tous les fichiers modifiés depuis le début de l'intégration (voir
aeib(1) pour plus d'informations) sont mis à jour depuis le début de la passe d'intégration.
L'ordre des heures de modification sera conservé, cependant la plage horaire sera
compressé le plus possible. Cela garantit que le développement ultérieur
les builds remarqueront que les fichiers de base ont changé.

Notez que s'il y a beaucoup de nouveaux fichiers avec des horodatages différents dans l'intégration
répertoire, et si le nombre de fichiers avec des horodatages différents dépasse le nombre de
secondes depuis le début de la commande d'integration-pass, Aegis peut avoir à définir le fichier
temps de modification dans le futur.

La build_time_adjust domaine du projet config fichier contrôle le comportement d'Aegis dans ce
Cas. (Voir aepconf(5) pour plus d'informations.) Il existe trois paramètres :

ajuster_et_sommeil
Ce paramètre, qui est la valeur par défaut, met Aegis en veille jusqu'à ce que le fichier
les temps de modification ne seraient plus dans le futur. Cela évite à la fois
les problèmes de construction de développement et les problèmes de construction d'intégration, tous deux
peuvent survenir en conséquence des temps de modification de fichier "intéressants".

ajuster_seulement
Aegis émettra un avertissement indiquant que les délais de modification des fichiers s'étendent jusqu'au
futur, mais ne dormira pas. Cela peut entraîner des problèmes de construction d'intégration,
surtout si vous utilisez aeintegratq(1). Les versions de développement peuvent fonctionner
constructions redondantes, cependant aet -reg ne doit pas produire de faux négatifs.

ne pas_ajuster
Ceci est hautement déconseillé. Il est fourni uniquement pour certains très rares
conditions. Ce paramètre empêche Aegis d'ajuster la modification du fichier
fois du tout. Cela peut avoir des effets secondaires très fâcheux, en particulier du
la construction d'intégration a été avant une ou plusieurs versions de développement ; le plus commun
symptôme étant que les constructions de développement ne provoquent pas toujours une reconnexion du
exécutables nécessaires, et aet -reg peut donner de faux négatifs. Il est fortement
recommandé de ne pas utiliser ce paramètre.

Si vous utilisez cuire(1), voir le réglage de l'heure indicateur pour savoir comment compresser la plage de temps même
plus loin. Cela raccourcit généralement considérablement le sommeil (ou la période d'avertissement).

Notification
En cas de réussite de cette commande, après que le renommage du répertoire s'est produit et
après la mise à jour de la base de données, le commande_de_notification_de_passe_d'intégration domaine de
les attributs du projet sont exécutés, s'ils sont définis. Voir aepattrde Géographie (5) et avec la aepa(1) pour plus d'informations.
Cette commande est exécutée en tant que propriétaire du projet.

Certains compilateurs enterrent les noms de chemin absolus dans des fichiers objets et des exécutables. Le renommage
du répertoire d'intégration pour devenir la nouvelle ligne de base rompt ces chemins. Ce qui précède
commande reçoit une variable d'environnement appelée AEGIS_INTEGRATION_DIRECTORY afin que le
le lien symbolique approprié peut être placé, si vous le souhaitez.

Les autres commandes exécutées par cette commande incluent le history_create_command, history_put_‐
commander et history_query_command domaines du projet config déposer. Voir aepconf(5) pour
pour en savoir davantage.

THE RÉFÉRENCE VERROUILLAGE

Le verrouillage de la ligne de base est utilisé pour garantir que la ligne de base reste dans un état cohérent pendant
la durée des commandes qui ont besoin de lire le contenu des fichiers dans la ligne de base.

Les commandes qui nécessitent que la ligne de base soit cohérente (celles-ci incluent le aeb(1),
aecpde Géographie (1) et avec la aed(1) commandes) prendre une ligne de base lire fermer à clé. Il s'agit d'un verrou non exclusif, donc
le développement simultané des changements n'est pas entravé.

La commande qui modifie la ligne de base, aeipass(1), prend une ligne de base écrire fermer à clé. Cette
est un verrou exclusif, forçant aeipass(1) pour bloquer jusqu'à ce qu'il n'y ait plus de lecture de ligne de base active
serrures.

Il est possible que l'une des commandes de développement ci-dessus se bloque jusqu'à ce qu'un
égide -Intégrer_PASS complète. Ceci est généralement de courte durée tandis que le projet
l'historique est mis à jour. Le délai est essentiel pour que ces commandes reçoivent un
vue de la ligne de base. Aucune autre commande d'intégration ne provoquera le développement ci-dessus
commandes à bloquer.

Lorsque la fonctionnalité de branche d'aegis est utilisée, un verrou en lecture (non exclusif) est pris sur le
la ligne de base de la branche ainsi que chacune des lignes de base "parentes". Cependant, une écriture de base
le verrouillage (exclusif) n'est pris que sur la ligne de base de la branche ; les lignes de base "parentes" ne sont que
lecture (non exclusive) verrouillée.

La Historique Verrouillage
Lorsqu'un projet a plusieurs branches actives simultanément, il est possible pour
commandes de pass d'intégration indépendantes pour différentes branches à émettre très près
ensemble. Le est une exclusivité Histoire bloquer prises par passe d'intégration pour s'assurer que seul
une branche met à jour l'historique du fichier à la fois, empêchant ainsi le fichier historique
la corruption.

TEST CORRÉLATIONS

La commande « aegis -Test -SUGgest » peut être utilisée pour que aegis suggère une régression appropriée
teste votre modification, en fonction des fichiers source de votre modification. Ceci automatiquement
concentre les efforts de test sur des tests pertinents, réduisant le nombre de tests de régression
nécessaire d'être sûr que vous n'avez pas introduit de bogue.

Les corrélations de test sont générées par la commande "aegis -Integrate_Pass", qui
associe chaque test de la modification à chaque fichier source de la modification. Ainsi, chaque
Le fichier source accumule une liste de tests qui lui ont été associés dans le passé.
Ce n'est pas aussi exact que l'analyse de couverture de code, mais c'est une approximation raisonnable dans
entraine toi.

La aecpde Géographie (1) et avec la aenf(1) les commandes sont utilisées pour associer des fichiers à une modification. Pendant qu'ils
n'effectuez pas activement l'association, ce sont les fichiers utilisés par aeipassde Géographie (1) et avec la
aet(1) pour déterminer quels fichiers sources sont associés à quels tests.

Le test Corrélation Précision
En supposant que les corrélations de test sont exactes et que les tests sont uniformément
répartis dans l'espace fonctionnel, il y aura moins de 1/nombre chance qu'un
le test pertinent n'a pas été exécuté par le "aegis -Test -SUGgest nombre" commande. Un petit
quantité de bruit est ajoutée à la pondération de test, de sorte que des choses inattendues sont parfois
testé, et les mêmes tests ne sont pas exécutés à chaque fois.

La précision de la corrélation des tests peut être améliorée en s'assurant que :

· Chaque changement doit être fortement ciblé, sans inclusions de fichiers gratuites. Cette
évite les fausses corrélations.

· Chaque élément de nouvelle fonctionnalité doit être ajouté dans un changement individuel, plutôt que
plusieurs ensemble. Cela corrèle fortement les tests avec la fonctionnalité.

· Chaque bogue devrait être corrigé dans un changement individuel, plutôt que plusieurs ensemble. Cette
corrèle fortement les tests avec la fonctionnalité.

· Les corrélations de test seront perdues si les fichiers sont déplacés. C'est parce que les corrélations sont par
nom.

Le meilleur moyen pour les tests d'établir une corrélation précise avec les fichiers source est lorsqu'un changement
contient un test et exactement les fichiers relatifs à la fonctionnalité testée. Trop
de nombreux fichiers parasites affaibliront l'utilité des tests de corrélation.

MÉTRIQUE

Aegis est capable d'enregistrer des métriques dans le cadre des attributs de fichier d'un changement. Cette
permet d'enregistrer diverses propriétés des fichiers pour une analyse de tendance ultérieure, ou d'autres
les usages.

Les métriques spécifiques ne sont pas dictées par Aegis. On s'attend à ce que l'intégration
build créera un fichier de métriques pour chacun des fichiers sources modifiés. Ces métriques
les fichiers doivent être au format spécifié par aémétrie (5).

Le nom du fichier de métriques par défaut est "nom de fichier,S”, cependant il peut être modifié, par
régler le metrics_filename_pattern domaine du projet config déposer. Voir aepconf(5)
pour plus d'informations.

Si un tel fichier de métriques existe, pour chaque fichier source dans un changement, il sera lu et
mémorisé au temps de passe intégré. S'il n'existe pas, Aegis suppose qu'il n'y a pas
métriques pertinentes pour ce fichier, et procède en silence ; Ce n'est pas une erreur.

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.

-Raison texte
Cette option peut être utilisée pour joindre un commentaire à l'historique des modifications généré par
cette commande. Vous devrez utiliser des guillemets pour isoler les espaces de la coque.

-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.

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 aeipass 'aegis -ipass \!* -v'
sh$ aeipass(){aegis -ipass "$@" -v}

LES ERREURS

C'est une erreur si la modification n'est pas attribuée à l'utilisateur actuel.
C'est une erreur si Le changement n'est pas dans le qui est des services Etat.
C'est une erreur s'il n'y a pas eu de succès 'égide -Construire' commande pour le
l'intégration.
C'est une erreur s'il n'y a pas eu de succès 'égide -Test' commande pour l'intégration.
C'est une erreur s'il n'y a pas eu de succès 'égide -Tester -Ligne de base' commande pour le
l'intégration.

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.

Utilisez aeipass en ligne en utilisant les services onworks.net