aedb - En ligne dans le Cloud

PROGRAMME:

Nom

égide développer commencer - commencer le développement d'un changement

SYNOPSIS

égide -Développer_Commencer changer-numéro [ option...]
égide -Développer_Commencer -Lister [ option...]
égide -Développer_Commencer -Aidez-moi

DESCRIPTION

Notre égide -Développer_Commencer La commande est utilisée pour commencer le développement d'un changement.

Le répertoire de développement de la modification sera créé automatiquement ; sous le
répertoire spécifié dans le champ default_development_directory de aeuconf(5), ou sinon
défini sous le répertoire spécifié dans le champ default_development_directory de
aepattr(5), ou s'il n'est pas défini sous le répertoire personnel de l'utilisateur actuel. Il est rare d'avoir besoin de
connaître le chemin exact du répertoire de développement, car le aecd(1) la commande peut vous emmener
là à tout moment.

L'exécution réussie de cette commande déplacera le changement spécifié de la attente
développant état à la qui est développé Etat. boxwid = 1 down S1 : box "en attente"
"développement" flèche "développer" ljuste "commencer" ljust S2 : case "être" "développer" T1 :
spline -> de S2.w puis à gauche 0.75 puis en haut 11/12 puis à 1/3 " développer "
ljust " commencer" ljust " annuler" ljust à T1.c - (0.75,0)

Notification
Notre développer_begin_command dans le fichier de configuration du projet (voir aepconf(5) pour plus
informations) sera exécuté, si spécifié. Ceci est exécuté après la libération des verrous d'égide,
des commandes aegis supplémentaires peuvent donc être exécutées à partir d'ici, si elles sont utilisées avec précaution. Les liens symboliques
(voir ci-dessous) ont pas encore été créé.

Développement Annuaire Emplacement
Veuillez Attention: Aegis consulte également le système de fichiers sous-jacent, pour déterminer sa notion de
taille maximale du fichier. Lorsque la taille de fichier maximale du système de fichiers est inférieure à
longueur_nom_fichier maximum, le système de fichiers gagne. Cela peut arriver, par exemple, lorsque vous êtes
en utilisant le système de fichiers Linux UMSDOS, ou lorsque vous avez un NFS monté sur un ancien V7
système de fichiers. Réglage longueur_nom_fichier maximum à 255 dans ces cas ne modifie pas le
fait que les limites des systèmes de fichiers sous-jacents sont beaucoup plus petites (12 et 14, respectivement).

Si vos répertoires de développement (ou l'ensemble de votre projet) se trouvent sur des systèmes de fichiers avec le nom de fichier
limitations, ou une partie des builds hétérogènes ont lieu dans un tel environnement,
cela aide à dire à Aegis ce qu'ils sont (en utilisant le projet config champs du fichier) afin que vous
ne vous heurtez pas à la situation où le projet s'appuie sur le plus permissif
environnements, mais échoue avec des erreurs mystérieuses dans les environnements les plus limités.

Si vos répertoires de développement se trouvent régulièrement sur un système de fichiers Linux UMSDOS, vous
il vaut probablement mieux régler dos_filename_required = oui, et aussi changer le
development_directory_template champ. Développement hétérogène avec différentes fenêtres
les environnements peuvent également l'exiger.

ADMINISTRATEUR OVERRIDE

Il est possible pour les administrateurs de projet d'utiliser le -Utilisateur option pour forcer un développeur à
commencer à développer un changement. Certains sites préfèrent fonctionner de cette façon. Notez que les développeurs
ont encore la possibilité d'utiliser le aedbu(1) commande.

Attention : l'utilisation capricieuse de cette commande va rapidement s'aliéner les développeurs. Le défaillant
les règles, notamment pour le numéro de changement, dépendent de l'égide et de l'accord du développeur sur
ce sur quoi le développeur travaille actuellement.

Notre Forced_develop_begin_notify_command attribut de projet (voir aepattr(5) pour plus
informations) sera exécuté lorsqu'un administrateur utilisera le -Utilisateur option, dans une tentative de
minimiser les surprises pour les développeurs. Une commande appropriée est
forcé_develop_begin_notify_command =
"$datadir/db_forced.sh $p $c $developer" ;
Cette commande enverra un e-mail au développeur, l'informant que le changement a été
lui est assigné.

SYMBOLIQUE LIENS

De nombreux outils de maintenance des dépendances, et même certains compilateurs, ont peu ou pas de support
pour inclure les chemins de recherche de fichiers, et donc pour le concept de répertoire à deux niveaux
hiérarchie employée par Aegis. (Il devient à plusieurs niveaux lorsque la fonctionnalité de branchement d'Aegis
est utilisé.) Pour permettre l'utilisation de ces outils, Aegis offre la possibilité de maintenir un ensemble
de liens symboliques entre le répertoire de développement d'un changement et la ligne de base d'un
projet, il apparaît donc à ces outils que tous les fichiers du projet sont présents dans le
répertoire de développement.

Projet Configuration
Notre style_répertoire_developpement champ du fichier de configuration du projet contrôle le
apparition du répertoire de développement. Voir aepconf(5) pour plus d'informations.

En utilisant un paramètre tel que
development_directory_style =
{
source_file_symlink = vrai ;
pendant_build_only = vrai ;
};
l'utilisateur ne voit jamais les liens symboliques, car ils sont ajoutés uniquement pour le bénéfice de
l'outil de maintenance des dépendances lors de l'exécution du aeb(1) commande.

En utilisant un paramètre tel que
development_directory_style =
{
source_file_symlink = vrai ;
};
(l'autre sera par défaut à false) les liens symboliques seront créés au début du développement
temps (voir aedb(1) pour plus d'informations) et également maintenu par chaque aeb(1) invocation.
Notez que les liens symboliques ne sont maintenus qu'à ces moments, donc les intégrations de projet
au cours de l'édition, les fichiers sourec de modification peuvent laisser les liens symboliques dans un
état incohérent jusqu'à la prochaine génération.

Lorsque des fichiers sont copiés à partir de la ligne de base dans une modification, à l'aide de la aecp(1) commande, le
le lien symbolique pointant vers la ligne de base, le cas échéant, sera supprimé avant que le fichier ne soit
copié.

Attention: L'utilisation de cette fonctionnalité sous l'une ou l'autre forme a des implications sur la façon dont le fichier de règles de
l'outil de maintenance des dépendances est écrit. Les règles doivent supprimez leurs cibles avant
les créer (généralement avec un rm -f commande) si vous utilisez l'un des sous-champs de lien (les deux
liens durs et liens symboliques). Ceci afin d'éviter d'essayer d'écrire le résultat sur le
lien symbolique, qui pointera vers un fichier en lecture seule dans la ligne de base du projet. C'est
similaire à la même exigence pour l'utilisation du lien_intégration_répertoire domaine de
fichier de configuration du projet.

Utilisateur Configuration
Il y a un symbolique_lien_preference dans le fichier de configuration utilisateur (voir aeuconf(5)
pour plus d'informations). Cela contrôle si aeb(1) vérifiera les liens symboliques
avant la construction (par défaut) ou s'il supposera qu'ils sont à jour. (Ce champ est
pertinent seulement si répertoire_de_développement__style.source_file_symlink est vrai.)

Pour les projets de taille moyenne à grande, la vérification des liens symboliques peut prendre autant de temps que le build
lui-même. Supposer que les liens symboliques sont à jour peut être un gain de temps considérable pour ces
projets. Il peut être conseillé de revoir votre choix de DMT dans une telle situation.

Notre aedb(1) commande pas consulter cette préférence. Ainsi, dans la plupart des situations, le
les liens symboliques seront à jour lorsque la construction sera effectuée. La seule fonction Aegis
ce qui peut rendre les liens symboliques obsolètes est l'intégration d'un autre
changer, car cela peut altérer la présence ou l'absence de fichiers dans la ligne de base. Dans ce
situation, la valeur par défaut aeb(1) l'action consiste à ignorer la préférence de l'utilisateur et la vérification
liens symboliques.

Il existe deux options de ligne de commande qui modifient aeb(1) comportement plus loin : le -Vérifier-
Liens-symboliques l'option dit de vérifier les liens symboliques ; et le -Assumer-les-liens-symboliques
option dit de supposer que les liens symboliques sont à jour. Dans chaque cas, l'option sur-
chevauche la valeur par défaut et la préférence de l'utilisateur.

Il est possible d'obtenir un comportement similaire à celui de Tom Lord'a Arch en utilisant un paramètre tel que :
development_directory_style =
{
source_file_link = vrai ;
source_file_symlink = vrai ;
};

Il est possible d'obtenir un comportement similaire à CVS en utilisant un paramètre tel que :
development_directory_style =
{
copie_fichier_source = vrai ;
};
Il existe de nombreuses autres configurations possibles du style_répertoire_developpement, Généralement
avec des effets secondaires de construction utiles. Voir aepconf(1) et le Dépendance Entretien Outil
chapitre du Guide de l'utilisateur pour plus d'informations.

Les options et préférences de la ligne de commande du lien symbolique s'appliquent également aux liens physiques et
copies de fichiers (les noms ont des origines historiques).

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.

-Annuaire chemin
Cette option peut être utilisée pour spécifier quel répertoire doit être utilisé. C'est une erreur
si l'utilisateur actuel n'a pas les autorisations appropriées pour créer le répertoire
chemin donné. Ce doit être un chemin absolu.

Attention : si vous utilisez un automounter, n'utilisez pas `pwd` pour faire un
chemin, il donne généralement la mauvaise réponse.

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

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

-Utilisateur prénom
Cette option est utilisée pour spécifier l'utilisateur qui doit développer le changement. Cette
L'option ne peut être utilisée que par un administrateur de projet.

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

LES ERREURS

C'est une erreur si le changement n'existe pas.
C'est une erreur si le changement n'est pas dans le attente développant Etat.
C'est une erreur si l'utilisateur actuel n'est pas un développeur du projet spécifié.

EXIT STATUT

Notre é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 aedb en ligne en utilisant les services onworks.net