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

Question

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

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

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

Answer 7

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

Answer 8

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

Answer 9

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

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

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

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

Answer 10

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

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

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

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

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

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

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