Филиалы Perforce Dev - Редкие ветки и частные ветки

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

Другим методом, который я слышал, является разветвление Sparse. Это описано в Практическое занятие (глава 9, с .242). Это создает ветку, но только с файлами, которые вам нужно будет отредактировать. Затем вы перекрываете представление клиента целевой ветки с помощью этого разреженного клиента.

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

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

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

Ответ 1

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

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

Ответ 2

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

Ответ 3

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

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

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