Контроль источника - блокировка против слияния?

Ответ 1

Перейдя с заблокированной модели на модель слияния, я сделаю следующие замечания:

• Большинство пользователей слияния, как правило, довольно близки к "головной" версии ветки, на которой они развиваются. Это обычно означает, что проблемы с драматическим слиянием не очень распространены.
• В течение примерно 10 лет использования модели слияния я испытал только пару очень плохих проблем слияния. В обоих случаях это было связано с тем, что 2 человека решили ту же проблему.
• Обычно мы разрешаем проблемы слияния без связи с другой стороной;)
• "Блокировка" модели VC в порядке, если система находится в стабильной фазе обслуживания с небольшими изменениями.
• Блокировка модели VC в порядке, если ваша команда мала (я бы сказал, 1-2 человека;)

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

Ответ 2

Я очень боялся идеи слияния себя, имея воспоминания о том, что в 1980-х годах пытались объединить код. Однако я загрузил Subversion и Git и немного поиграл с ними, и я впечатлен их обещанием. Стыдно, что я единственный, кто здесь.

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

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

4 - единственная ситуация, когда можно утверждать, что блокировка помогла вам и охватывает каждое такое событие. То, что я нашел за последние 3 года, я делал так, что почти каждая проблема относится к разнообразию 1-3. Кажется, я нашел 4 раза. Но если я все время теряю до 1-3, это потрясающе.

Ответ 3

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

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

Кроме того, имейте в виду, что есть также возможность иметь комбинацию обоих:

• "lock": первый разработчик, который изменит файл, будет первым, кто его совершит. Каждый другой разработчик может также модифицировать один и тот же файл, но ему придется дождаться завершения первого, прежде чем начинать слияние собственных изменений.
• "merge": когда разработчик фиксирует файл, уже измененный коллегой, он объединяет свои изменения.

В этом случае вы должны убедиться, что существует механизм "выпуска", чтобы избежать блокирования первым разработчиком.

Ответ 4

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

Вероятно, почему это модель по умолчанию в большинстве современных систем управления версиями.

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

Ответ 5

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

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

Блокировка реактивна... merge proactive...

Ответ 6

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

Ответ 7

Самые большие проблемы слияния, которые я когда-либо имел, были на сайте, где у нас была блокировка контроля версий (точнее, SCCS - это было давно).

Что произойдет, так это то, что человек A будет работать над чем-то, и файл будет проверен. Человек B получит срочный запрос на исправление чего-либо для клиента и должен будет изменить этот файл.

Это разыгрывалось несколькими способами. Иногда A будет регистрироваться, B внесет изменения, и A затем продолжит работу с рабочей копии и уничтожит B-изменение. Иногда B начинал с скопированной копии, поскольку время было сущностью, и изменения могли занять некоторое время, чтобы получить право, и перезаписать изменения A. Иногда изменения B будут взаимодействовать с изменениями A, а некоторые из изменений A будут искажены или потеряны. В последнем случае предупреждения не было.

В слиянии VCS, A и B вносят свои изменения, и система гарантирует, что ничего не потеряно. В последнем случае VCS отмечает конфликт, поэтому он не будет пропущен.

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

Я никогда не видел производственной среды, где можно было гарантировать, что двум людям не придется работать над одним и тем же файлом примерно в одно и то же время. Слияние VCS прекрасно справляется с этой ситуацией. Блокировка VCS не работает.

Ответ 8

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

Ответ 9

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

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

В распределенных системах управления версиями, таких как Git, каждая проверка по существу является ветвью.

Ответ 10

Блокирующие сторонники ошибаются, если есть такая вещь, как тот, кто защищает это. Каждая команда, с которой я встречалась, использовала старую систему стиля блокировки, жаловалась на нее и с любопытством смотрела на людей, использующих другие методы. Я работал над проектом для одного места, которое было вынуждено использовать систему блокировки и вообще не использовало NO CONTROL (поэтому я создал секретную ветвь SVN, хотя я предпочитаю Bzr или Git).

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

Ответ 11

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

В глупых приложениях может использоваться подход слияния, но если мы говорим о серьезных системах... как банковские системы и т.д.

Ответ 12

Общая жалоба на блокировку VCSes заключается в том, что у вас есть проблема, когда кто-то отправляется на отпуск или конференцию, оставляя некоторые файлы заблокированными:)