Perforce: Как файлы хранятся с ветвлением?

Question

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

Рассмотрите проблему разветвления десятков Gb. Что происходит, когда вы создаете ветвь этого огромного количества информации?

Я читаю официальный документ here и here, но до сих пор не понимаю, как файлы хранятся для каждой ветки на сервере.

Скажем, файл A.txt существует в основной ветке. При создании ветки (Xbranch) и рассмотрении A.txt не будет изменений, будет ли сервер perforce дублировать файл A.txt (один из которых содержит основные изменения, а другой для Xbranch)?

Для огромного количества данных это становится вопросом, потому что это будет означать дублирование десятков Gb. Так как это действительно работает?

Answer 1

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

Perforce относится к ним как «ленивые копии»; вы можете узнать о них подробнее здесь: http://answers.perforce.com/articles/KB_Article/How-to-Identify-a-Lazy-Copy-of-a-File

Единственное исключение - если вы используете модификатор типа «+ S», так как в этом случае каждая ветка будет иметь свою собственную копию содержимого, так что семантика + S может быть правильно выполняются на каждой ветви независимо.

Answer 2

Некоторые замечания в дополнение к ответу Брайан Пендлтон (и вопросы из него)

Чтобы действительно проверить ваше понимание того, что происходит, это хорошо, чтобы попытаться с тестовым хранилище с небольшим количеством файлов и создать контрольные точки после каждого основного действия, а затем сравнить контрольные точки, чтобы увидеть, какие фактические строки базы данных были написаны (а также просмотреть архивные файлы, которые поддерживает сервер). Это очень быстро и легко настроить. Вы заметите, что каждый разветвленный файл генерирует записи в db.integed, db.rev, db.revcx и db.revhx - не говоря уже о любом из db.have.

Вам также необходимо знать, какую версию сервера вы используете, поскольку поведение со временем улучшилось. Проверьте вывод «p4 помощи Уничтожение»:

Obliterate знает о ленивых копиях, когда «p4 интеграции» создает ветвь, и не удаляет копии, которые до сих пор. Поскольку этого, стирающие файлы не гарантируют, что соответствующие файлы в архиве будут удалены.

Некоторых другие точки:

• флаги по умолчанию для «p4 интегрирует», чтобы создать филиалы были скопированы файлы вплоть до клиента рабочей области, а затем копировали их обратно на сервер с отправкой. Это потребовало времени в зависимости от того, сколько и сколько файлов было. Этого уже давно можно избежать, используя флаг -v (virtual), который просто создает соответствующие строки на сервере и избегает обновления рабочей области клиента - как правило, намного быстрее. Возможный недостаток - вам нужно синхронизировать файлы после этого, чтобы работать над ними.
• Новые версии Perforce имеют команду «p4 populate», которая делает то же самое, что и «интегрировать -v», но на самом деле не требует, чтобы целевые файлы отображались в текущее рабочее пространство клиента - это позволяет избежать ужасной «цели» файл (ы) в представлении клиента ", с которым многие новички боролись! [В P4V это команда «Файлы филиалов ...» в меню правой кнопки мыши, а не «Слияние/Интеграция ...»]
• Потоки сделали разветвление много более легким и легким во многих отношениях - стоит посмотреть (единственная потенциальная муха в мазене - это плоская иерархия именования уровня 2, а также потенциальные проблемы при переносе существующих ветвей с существующими отношениями в потоки)
• Потоки задач довольно изящны и экономят много места на сервере
• В Obliterate был интересный флаг -b для нескольких выпусков, который походит на возможность быстрого и простого удаления неизмененных файлов ветвей - так, как ретро-создание потока задач. Может потенциально экономить миллионы строк базы данных в больших установках с большим количеством ветвлений