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

Question

Я всегда использовал Subversion или CVS для контроля версий, которые используют методологию слияния. Один из моих друзей в восторге от Perforce и его великолепия благодаря спискам изменений и методике проверки.

Хотя я уверен, что многое из этого сводится к опыту и личным предпочтениям, мне было интересно, было ли проведено какое-либо исследование в отношении того, какой метод контроля версий более эффективен для работы?

РЕДАКТИРОВАТЬ: Чтобы уточнить, я знаю, что как Perforce, так и SVN допускают блокировку и объединение, но SVN «поощряет» либеральный метод редактирования и слияния, тогда как, насколько я понимаю, Perforce рекомендует метод checkout-checkin. .

Answer 1

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

Answer 6

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

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

Answer 7

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

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

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

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

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

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

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

Answer 8

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

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

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

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

Answer 9

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

Answer 10

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