Как упомянуто в «Какие основные концепции clearcase должен знать каждый разработчик?» , ClearCase поддерживает механизм блокировки, который одновременно:
"пессимистично": зарезервировано оформить заказ на самом деле не мешает другим людям делать свои собственные заказы, но им придется подождать, пока человек извлечет файл как "зарезервированный" чтобы выполнить регистрацию: никто не может выполнить регистрацию, пока этот человек не выполнит первую регистрацию (тогда каждый пользователь должен будет объединить свою версию с последним зарегистрированным файлом)
Примечание: «зарезервированный» извещатель может снять блокировку и быть оставлен незарезервированным владельцем или администратором;
«оптимистично»: незарезервированная проверка , что означает (если никто не использует зарезервированную проверку для того же файла): первый, кто зарегистрировался, может сделать это без каких-либо других операций, другой им придется объединить свою работу с последним зарегистрированным файлом.
В срок, если политика использования:
- Как правило, зарезервированный заказ - это хорошо, поскольку он позволяет вам вносить изменения с «высокой приоритетностью»: их необходимо учитывать в первую очередь.
- Для локальных модификаций, которые не нужно регистрировать сразу, достаточно безоговорочной проверки.
- Для локальных модификаций, которые вообще не нужно регистрировать, достаточно угнанного файла или затмеваемых файлов (так что проверки вообще нет)
Примечания:
A cleartool checkout/checkin не совпадает с:
svn checkout / git checkout, которые обновляют рабочий репозиторий с содержимым ревизии / фиксации, а не извлекают версию файла : набор файлов против одного файла. - "checkin":
svn commit / git commit, который зарегистрировал изменения, возможно, нескольких файлов в хранилище (удаленно для SVN, локально для Git ), в отличие от создания новой версии для одного файла.
У самого Git не было бы "блокировки файлов" (зарезервированная проверка). Только система, использующая Git, может предложить эту функцию, например Git LFS .