aeclone - Интернет в облаке

ПРОГРАММА:

ИМЯ

aegis clone - сделайте точную копию изменения

СИНТАКСИС

эгида -CLone [ вариант...] номер изменения [номер изменения]
эгида -CLone -Помощь
эгида -CLone -Версия

ОПИСАНИЕ

The эгида -CLone команда используется для создания точных копий изменений. Это из большинства
используйте, когда необходимо применить изменение к нескольким параллельным ветвям.

Один номер изменения обязательно быть поставленным. Это изменение, которое нужно воспроизвести. Если есть ветка
приведены варианты (см. ниже) номер обязательного изменения применяется к филиалу
указано. Если ветка не указана, изменение применяется к проекту (неявно или неявно).
явный).

Если указан необязательный второй номер изменения, это номер изменения, который необходимо создать.
держать реплику; если он не предоставлен, следующий доступный номер изменения будет
используемый.

Если реплицируемое изменение было выполнено, соответствующие версии файла будут
извлечены из истории; в противном случае файлы будут скопированы из каталога разработки
изменения, которое нужно скопировать. Будьте осторожны: если файл в изменении, который был клонирован
впоследствии изменяется, эти изменения предусматривает автоматически отслеживаться. Лучше всего, если
изменения клонируются в стабильное время, такое как одно из состояний после завершения разработки или даже
после интеграции пройти.

Разработка Каталог Локация
Пожалуйста, Примечание: Aegis также обращается к базовой файловой системе, чтобы определить ее понятие
максимальный размер файла. Если максимальный размер файла файловой системы меньше, чем
максимальная_имя_файла_длина, файловая система выигрывает. Это может произойти, например, когда вы
с использованием файловой системы Linux UMSDOS или когда у вас есть NFS, смонтированная на древнем V7
файловая система. Параметр максимальная_имя_файла_длина до 255 в этих случаях не меняет
Дело в том, что ограничения для базовых файловых систем намного меньше (12 и 14 соответственно).

Если ваши каталоги разработки (или весь ваш проект) находятся в файловых системах с именем файла
ограничения, или часть разнородных сборок происходит в такой среде,
помогает рассказать Aegis, что они из себя представляют (используя проект конфиг поля файла), чтобы вы
не попадайте в ситуацию, когда проект строится на более разрешительных
средах, но терпит неудачу с загадочными ошибками в более ограниченных средах.

Если ваши каталоги разработки обычно находятся в файловой системе Linux UMSDOS, вы должны
наверное, лучше было бы устроить dos_filename_required = правда, а также изменение
development_directory_template поле. Гетерогенная разработка с различными окнами
окружающая среда также может потребовать этого.

БЕЛЫЙ

Aegis предоставляет вам то, что часто называют «путем просмотра», которое указывает на необходимость разработки.
инструменты (компиляторы, системы сборки, и т.д) посмотрите сначала в каталоге разработки, затем в
базовая линия ветви и так далее до базовой линии ствола.

Проблема с путями просмотра в том, что для удаления файлов вам понадобится какой-то
"белое пятно", чтобы сказать: "хватит смотреть, его убрали".

Когда вы используете Aerm(1) или AEMV(1) команды, это означает "добавить информацию к этому изменению
который удалит файл из базовой линии, когда это изменение будет интегрировано ". Т.е. в то время как
изменение в не являетесь развитый состояние, файл удаляется только при разработке
каталог - он по-прежнему присутствует в базовой линии и будет существовать до тех пор, пока не будут внесены изменения.
успешно интегрирован.

Когда вы используете Aerm(1) или AEMV(1), Aegis создаст файл размером 1К, который будет действовать как
белая тьма. Его содержимое довольно уродливое, поэтому, если вы скомпилируете или включите "удаленный"
файл случайно, вы получите фатальную ошибку. Это напомнит вам удалить устаревшие
Рекомендации.

Когда изменение интегрировано, удаленный файл скопировано / связано с базовой линией на
каталог интеграции, и скопировано из каталога разработки. На это
время его физически нет (нет белого налета). Предполагается, что из-за ошибки
вызывая белые пятна, все старые ссылки были найдены и исправлены, пока изменение было в
не являетесь развитый состоянии.

Файл Манифесты
При создании списка файлов для компиляции или связывания важно, чтобы файл
manifest генерируется на основе информации, известной Aegis, а не из файловой системы.
На это есть несколько причин:

(a) Aegis точно знает, какие (исходные) файлы и где находятся, в то время как все остальное
вывод знаний Aegis; а также

(б) поиск в файловой системе затруднен, если путь просмотра длиннее двух каталогов
(а метод ветвления Aegis может сделать его сколь угодно длинным); а также

(c) Белые файлы и все остальное, что «валяется без дела», запутает любой метод.
который опрашивает файловую систему.

Самый простой способ использовать знания Aegis о файлах - это использовать что-то вроде AWK(1) сценарий
обработка списков файлов Aegis. Например, вы можете сделать это с помощью сделать(1) следующим образом:
# генерировать манифест файла
манифест.make.inc: манифест.make.awk
(aegis -l cf -ter; aegis -l pf -ter) | \
awk -f manifest.make.awk> manifest.make.inc
# теперь включаем файл-манифест
включить manifest.make.inc
Примечание: это было бы неэффективно, если бы вы сделали это один раз для каждого каталога, но нет ничего
мешает вам писать многочисленные задания в манифест.make.inc файл, все в одном
проходить.

То же самое можно сделать и с генератором отчетов Aegis (см. Aer(1) подробнее
информации), но это более сложно, чем AWK(1) сценарий. Однако с
информация как бы «прямиком из конского рта», тоже может быть намного умнее.

Этот манифест файла устарел без блокировки файла Aegis.
команды операций. Используя проект-файл_команда и команда изменения_файла поля
проект конфиг файл (см. aepconf(5) для получения дополнительной информации), вы можете удалить этот файл
в стратегические моменты.
/ * запускаем при изменении манифеста файла изменений * /
change_file_command = "rm -f manifest.make.inc";
/ * запускаем при изменении манифеста файла проекта * /
project_file_command = "rm -f manifest.make.inc";
Таким образом, новый файловый манифест будет перестроен во время следующего AEB(1) команда.

Варианты и Настройки
Eсть -Нет опция, которая может использоваться для подавления белых затемненных файлов при использовании
Aerm(1) и AEMV(1) команды. Соответствующий -Белый вариант, который
обычно по умолчанию.

Eсть whiteout_preference в файле настроек пользователя (см. aeuconf(5) для
подробнее), если вы хотите установить эту опцию на более длительный срок.

Белая мгла Файл Шаблоны
The whiteout_template область проекта конфиг файл может быть использован для создания языка
конкретные файлы ошибок. Если ни одна запись шаблона whiteout не соответствует, очень уродливый файл размером 1 КБ будет
быть произведенным - он должен вызывать ошибки компилятора практически для любого языка.

Если вам нужно более удобочитаемое сообщение об ошибке, такие записи, как
белый_шаблон =
[
{
шаблон = ["*. [ch]"];
body = "#error Этот файл удален.";
}
];
может быть очень эффективным (в этом примере предполагается GCC(1) используется).

Если необходимо, чтобы нет файл whiteout, скажем, для исходных файлов C, вы можете
используйте шаблон белого цвета, например
белый_шаблон =
[
{шаблон = ["* .c"]; }
];
потому что отсутствует тело Подполе означает, что файл белого затемнения не создается.

У вас может быть более одной записи шаблона whiteout, но обратите внимание, что порядок
записи важны. Первая запись, которая будет использоваться.

Уведомления
Команды уведомления, которые будут запускаться AECP(1) аэдб(1) анф(1) Aent(1) и
Aerm(1) выполняются соответствующие команды. В проект_файл_команда также запускается, если установлено.
Посмотреть aepconf(5) для получения дополнительной информации.

Клонирование и Объединение

Когда вы используете весы для поддона эклон(1), чтобы клонировать набор изменений, а затем интегрировать одно из двух изменений
наборы, вы увидите, что Aegis сообщает, что файлы неинтегрированного изменения теперь
устаревший.

Если вы запустите AEM(1) восстановить устаревшие файлы в актуальном состоянии, Fmerge(1) и некоторые (но
не) все другие инструменты слияния, он сигнализирует обо всем как о конфликте, даже если
обе альтернативы идентичны.

Проблема в том, что два изменения вносят одинаковые правки в одно и то же место в одном файле.
являются логическим конфликтом, даже если это не реальный конфликт, и требуется человек, чтобы понять
из разницы. Подумайте о списке покупок: в ванной нужно больше мыла, и тоже.
основная ванная комната. Второе «мыло» о слиянии двух списков покупок - это не
дубликат, вам действительно нужны две коробки мыла. Иногда редактирование исходных файлов
то же самое: иногда логический конфликт разрешается путем применения обоих одинаковых правок, а не
только один.

Это просто Fmerge(1) команда более консервативна, чем RCS слияние(1) команда.

Самый простой способ справиться с этой распространенной ситуацией - запустить
aecpu - без изменений
команду до вы управляете AEM(1) команда слияния, и у вас будет меньше горя. Это также
стоит помнить, что Aegis хранит исходный файл с суффиксом a, B (B для резервной копии), поэтому
ты можешь просто
mv FUBAR,B FUBAR
если вы знаете, что все конфликты являются логическими конфликтами.

ДОПОЛНИТЕЛЬНЫЕ ОПЦИИ

Подразумеваются следующие варианты:

-Ветвь номер
Эта опция может использоваться для указания другой ветки для исходного файла, а не
чем базовый уровень. (Смотрите также -Сундук вариант. Обратите внимание: -Ветвь вариант
не принимает имя проекта, только суффикс номера ветки.

-прародитель
Эту опцию можно использовать для указания ветки дедушки и бабушки (на одну выше
текущая ветвь) для исходного файла, а не для базовой линии. (Дедушка
опция такая же, как опция «-ветвь ..».)

-Изменять номер
Этот параметр можно использовать для указания конкретного изменения в проекте. Видеть
эгида(1) для полного описания этой опции.

-КАТАЛОГ путь
Эта опция может использоваться, чтобы указать, какой каталог будет использоваться. Это ошибка
если у текущего пользователя нет соответствующих разрешений на создание каталога
путь дан. Это должен быть абсолютный путь.

Внимание: если вы используете автомонтаж, не используйте pwd для абсолютного
путь, обычно дает неправильный ответ.

-Помощь
Эта опция может использоваться для получения дополнительной информации о том, как использовать эгида
программу.

-Список
Эта опция может использоваться для получения списка подходящих субъектов для этой команды.
Список может быть более общим, чем ожидалось.

-Белый
Эта опция может использоваться, чтобы запросить замену удаленных файлов на «белое пятно».
файл в каталоге разработки. Идея состоит в том, что компиляция такого файла будет
приведет к фатальной ошибке, чтобы можно было найти все ссылки. Это
обычно по умолчанию.

-No_WhiteOut
Эта опция может использоваться, чтобы запросить, чтобы в
каталог разработки.

-Выход имя файла
Эта опция может использоваться для указания имени файла, которое должно быть записано с
автоматически определяемый номер изменения. Полезно для написания скриптов.

-Проект имя
Эта опция может быть использована для выбора интересующего проекта. Когда нет -Проект
опция указана, ЭГИС_ПРОЕКТ переменная среды консультируется. Если
которого не существует, пользователь $ HOME / .aegisrc файл проверяется на предмет дефолта
поле проекта (см. aeuconf(5) для получения дополнительной информации). Если этого не существует,
когда пользователь работает только над изменениями в рамках одного проекта, проект
имя по умолчанию для этого проекта. В противном случае это ошибка.

-Сундук
Эта опция может использоваться для указания ствола проекта для исходного файла, а не
чем базовый уровень. (Смотрите также -Ветвь опция -trunk такая же, как
вариант «-ветвь -».)

-Ждать Эта опция может использоваться для того, чтобы команды Aegis ожидали блокировки доступа, если
их нельзя получить сразу. По умолчанию для пользователя lock_wait_preference
если не указано, см. aeuconf(5) для получения дополнительной информации.

-Нет, подождите
Эта опция может использоваться для того, чтобы команды Aegis выдавали фатальную ошибку, если доступ
замки нельзя получить сразу. По умолчанию для пользователя
lock_wait_preference если не указано, см. aeuconf(5) для получения дополнительной информации.

Смотрите также эгида(1) для параметров, общих для всех команд aegis.

Все параметры могут быть сокращены; аббревиатура оформляется заглавными буквами,
все строчные буквы и символы подчеркивания (_) необязательны. Вы должны использовать последовательные
последовательности необязательных букв.

Все параметры нечувствительны к регистру, вы можете ввести их в верхнем или нижнем регистре или
сочетание того и другого, случай не важен.

Например: аргументы «-project», «-PROJ» и «-p» интерпретируются как означающие
-Проект вариант. Аргумент "-prj" не будет понят, потому что последовательные
необязательные символы не были предоставлены.

Параметры и другие аргументы командной строки могут быть произвольно смешаны в командной строке,
после переключателей функций.

Понятны длинные имена опций GNU. Поскольку все имена опций для эгида длинные,
это означает игнорирование лишнего начала "-". "--вариант=ценностное "конвенция также
понят.

ОШИБКИ

Это ошибка, если текущий пользователь не является администратором проекта. (В некоторых
случаи, когда разработчики проекта могут вносить изменения, см. эпатр(5) для
больше информации.)

ВЫХОД статус

The эгида команда завершит работу со статусом 1 при любой ошибке. В эгида команда будет только
выйти со статусом 0, если ошибок нет.

ОКРУЖАЮЩАЯ СРЕДА ПЕРЕМЕННЫЕ

Посмотреть эгида(1) для списка переменных среды, которые могут повлиять на эту команду. Видеть
aepconf(5) для файла конфигурации проекта проект_специфический поле для установки
переменные среды для всех команд, выполняемых Aegis.

Используйте aeclone онлайн с помощью сервисов onworks.net