Perforce Dev Branch - разреженное ветвление против частного ветвления

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

Другой рекомендуемый метод - это разреженное ветвление. Это описано в Practical Perforce (глава 9, стр. 242). Это создает ветку, но только с файлами, которые вам нужно отредактировать. Затем вы перекрываете представление клиента целевой ветви с этим разреженным представлением клиента ветви разработки.

Оба метода потребуют от программиста выполнения некоторой работы по интеграции, чтобы получить свои изменения в целевой ветви. Кажется, что для метода Private Branch потребуется намного больше дополнительной памяти, чтобы создать копию всей ветки. Однако в документации Perforce указано, что в этой ситуации он выполняет «ленивое копирование».

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

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


person Community    schedule 07.04.2009    source источник


Ответы (3)


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

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

person grieve    schedule 07.04.2009

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

person Douglas Leeder    schedule 08.04.2009
comment
Хорошая точка на клиентском дисковом пространстве. Я забыл указать на это, так как у меня на машине есть ТБ свободного места, но в большинстве случаев это все еще актуально. - person Fostah; 08.04.2009

Хорошая ситуация, для которой подходит разреженное ветвление, - это когда у вас есть сложный продукт, потенциально состоящий из множества модулей. Скажем, сборка занимает много времени для всей системы и, возможно, требуется время для синхронизации - много файлов данных. Но ваша разработка должна изменить только небольшое подмножество всей исходной базы - возможно, модуль или два, возможно, с некоторым кодом связывания «выше».

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

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

person Greg Whitfield    schedule 09.04.2009