2016-12-29 1 views

ответ

0

Главное преимущество cleartool lock -obs заключается в том, чтобы команды/графический интерфейс, перечисляющие эти объекты, по умолчанию не отображали устаревшие.
(See FAQ)

Вот почему вы бы устаревшие ветви или потоки, этикетка или исходные условия: графический lsvtree будет намного шустрее без необходимости перечислять все эти объекты.

Но действия? Это будет иметь значение, если эти действия по-прежнему будут представлены в качестве выбора при проверке файла. Если они нет (потому что, например, их поток уже устарел), то это не будет иметь большого влияния.
См. "What do we need to lock/obsolete to discontinue a project?"

+0

Спасибо за ввод. У нас просто огромный монолитный VOB, который имеет 10 лет проектов/истории, которые больше никогда не будут рассмотрены. Я хочу исключить их из отображения при подключении к действительным проектам и не хочу, чтобы они отображались на деревьях версий. Я просто задавался вопросом, насколько глубоки мы должны пойти с переутомлением, чтобы улучшить производительность. Похоже, что мы не очень много покупаем. В его нынешнем виде мы израсходовали 3 или 4 дюжины проектов, и в пределах примерно 1800 потоков. Мы работаем над отключением ветвей. –

+0

@JonShanks да, ветви ветвления (и связанные потоки), а также базовые линии помогут сохранить дерево версии мгновенно. – VonC

0

Еще одно соображение - количество видов деятельности/потоков/проектов, о которых идет речь. Если вы создаете что-то вроде 90% активности, то вам может понадобиться уйти в отставку с указанными потоками и создать новые. Если вы делаете это до 90% потоков в проекте, возможно, вам захочется рассмотреть вопрос о выходе из проекта и создании нового.

Устаревшая блокировка не предотвращает поиск объектов (например, для получения списка действий в потоке), это просто предотвращает их отображение по умолчанию в графическом интерфейсе или в командной строке.

Смежные вопросы