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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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