Какая методология контроля версий более эффективна: извлечение или слияние?

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

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

Я использую Perforce прямо сейчас и почему-то мне больше нравится SVN. Perforce определенно дает мне лучшее представление о том, что будут конфликты слияния, и даже имеет встроенные инструменты, которые помогут мне разрешить слияния. Это та же проблема, что если кто-то вносит массу изменений в течение длительного времени, слияние будет сложнее.

Обычно обе модели требуют частой регистрации изменений. Если вы сделаете много проверок, вы уменьшите вероятность того, что вам потребуется слияние. Я виноват в том, что слишком долго проверяю вещи. Лично мне кажется, что цена SVN компенсирует все, чего ему не хватает по сравнению с Perforce; Я пока не нашел между ними разницы.

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

Обратите внимание, что Perforce не применяет методологию проверки, она разрешает одновременные проверки (эквивалент слияния).

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

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

Отслеживание Perforce отношений между филиалами является огромным преимуществом. Если Subversion реализовала это сейчас, сообщите мне, пожалуйста.

Возможно, вы имели в виду Source Safe, а не Perforce? Perforce поддерживает слияние, и на самом деле у него была лучшая поддержка слияния, чем у SVN до SVN 1.5, где были добавлены именованные слияния (а также списки изменений, которые всегда были у Perforce, и я очень сильно перехожу в магазин, который использовал SVN, но мы выиграли '' t обновление до 1.5 было немного больше проверено временем.)

Стоит отметить, что SVN и Perforce позволяют выполнять заблокированную проверку, поэтому при желании вы можете использовать модель «без объединения», но, кроме, возможно, управления двоичными файлами с контролем версий, я не вижу в этом особого смысла.

В любом случае, простой ответ на ваш вопрос - «модели слияния намного лучше, когда задействовано более одного разработчика».

Если я правильно понимаю, Perforce делает все файлы, которые не были извлечены, доступными только для чтения. Это похоже на поведение в Microsoft TFS и VSS. Subversion, с другой стороны, не устанавливает атрибуты только для чтения. ИМО, метод Subversion проще, потому что вам не нужно возиться с клиентом системы управления версиями, чтобы изменять файлы - вы продолжаете и безрассудно изменяете, а затем сравниваете то, что изменилось на диске, с сервером, когда будете готовы зарегистрироваться.

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

Если я правильно понимаю, Perforce делает все файлы, которые не были извлечены, доступными только для чтения.

Это только поведение по умолчанию. При необходимости, часто изменяющиеся файлы могут быть настроены на чтение-запись. См. Полный список модификаторов файлов здесь.

Кроме того, в своей среде я использую Eclipse с подключаемым модулем Perforce. С помощью этого плагина редактирование файла немедленно открывает файл для редактирования.

Не уверен насчет исследования, но вот вам один пункт данных:
Моя команда выбрала PVCS (оформление заказа) в основном из-за удобства. Сомнения по поводу слияния и незнание таких инструментов, как Subversion, определенно способствовали этому.

Я не уверен, что понимаю вопрос здесь - я не знаю ни одной современной системы управления версиями (кроме Visual SourceSafe), которая не полностью поддерживает слияние.

Я определенно предпочитаю методологию слияния.

Я использовал Visual Sourcesafe (надеюсь, больше никогда), CVS, subversion и bzr. Visual sourcesafe применяет методологию «проверки перед редактированием» и может быть болезненным. CVS и Subversion исторически не очень хорошо принимали слияния, хотя я слышал, что в Subversion 1.5 это улучшилось.

Я бы порекомендовал использовать VCS, который изначально разрабатывался с учетом частых слияний. Для этого я использовал bzr, но и другие основные распределенные системы vcs (git и mercurial) тоже.

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

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

В Perforce, если кто-то регистрирует файл, который вы также изменяете, то при следующей синхронизации с сервера (т. Е. При получении последних файлов) вы получаете информацию о некоторых изменениях, которые необходимо исправить. Выбор того, когда это сделать, зависит от вас. Когда вы «разрешаете» файл, он выполняет слияние с вашей локальной версией - и инструменты для этого подходят.

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

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

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

Perforce очень четко дает вам выбор и контроль над распространением изменений и подкрепляет это отличными инструментами для управления объединением правок. Лично мне нравится выбор и способность легко осуществлять выбор. Несомненно, у Subversion есть свои альтернативы.

Я полагаю, это, вероятно, сводится к тому, к чему вы привыкли - я не думаю, что существует значительная или измеримая проблема эффективности.