Можем ли мы создавать ярлыки в принудительном порядке

Perforce также предоставляет интересное руководство "Руководство по планированию миграции: IBM Rational ClearCase to Perforce", и упомянем, что p4 label — не единственная альтернатива:

Стратегии этикеток

Как ClearCase, так и Perforce предоставляют метки, идентифицирующие версии файлов, составляющие базовый уровень. Для многих пользователей ClearCase метки являются обязательными. Применение меток занимает много времени, часто на его долю приходится 30 и более процентов времени, связанного с созданием стабильных сборок.

В Perforce метки — это всего лишь один из способов воспроизведения базовых показателей. Списатели изменений достигают той же цели способами, которые менее утомительны для процесса сборки, а также быстрее и проще для ссылок, чем метки.

Каждая регистрация Perforce создает уникальный номер списка изменений, отражающий состояние репозитория в определенный момент времени. Любой список изменений можно использовать для описания состояния каждого файла в репозитории, даже если он влияет только на небольшое подмножество репозитория.

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

Да, вы можете создавать метки в принудительном порядке.

Используйте p4 label для создания спецификации метки, а затем используйте p4 tag для пометки файлов.

Вы можете узнать больше о ярлыках в разделе < href="http://www.perforce.com/perforce/doc.current/manuals/p4guide/" rel="nofollow">руководство пользователя.

Представьте, что у вас есть следующая установка:

//depot/source/sourcefile.cpp
//depot/build/product.exe

В 8 утра вы регистрируете исходный файл.cpp (сейчас ревизия 2, в списке изменений 100). Машина сборки начинает сборку, и в 9 утра машина сборки проверяет product.exe, ревизию 2 в списке изменений 104. Круто. К сожалению, вы, возможно, не заметили, но в 8:15 кто-то проверил ревизию 3 исходного файла.cpp в списке изменений 103.

Каковы ваши варианты? Если вы просто записываете список изменений источника (100) и продукта (104), вы можете синхронизировать весь проект с исходным кодом, а затем синхронизировать содержимое списка изменений 104. Этот процесс выполняется несколько вручную — вам нужно записать два числа. и выполните двухэтапную операцию.

Вы можете сделать метку, но, к сожалению, метки не допускают множественных изменений, так что это не очень удобно.

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

p4 integ //depot/source/...@102 //depot/milestone1/source/...
p4 integ //depot/build/...@104 //depot/milestone1/build/...

Необычные детали — вы можете настроить файлы так, чтобы они содержали ограниченное количество ревизий — например, вам могут понадобиться только последние 16 ревизий product.exe. (Измените тип файла на +S16). Если вы (или кто-то другой сделает это), первые две процедуры в конечном итоге потерпят неудачу, потому что ревизия была удалена из-за слишком большого количества ревизий. Если вы используете ветку, ваш product.exe не устареет.