Perforce Dev Branches - Разветвленное ветвление против частного.

Question

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

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

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

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

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

Answer 1

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

Answer 2

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

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

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

Answer 3

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

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