Блокировка ревизионного контроля: жюри все еще отсутствует?

Question

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

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

Мой вопрос не в том, кто прав. Я почти уверен, какой ответ я получу на это. Мой вопрос заключается в том, есть ли еще какие-либо дебаты по этому вопросу? Есть ли честный лагерь "про блокировку", который делает серьезное дело? Делается ли какая-либо работа по продвижению искусства контроля версий, основанного на модели блокировки? Или блокирующие вентиляторы порют мертвую лошадь?

EDIT: Ответы до сих пор хорошо объясняли, почему эксклюзивные блокировки иногда полезны. Однако я говорю о продвижении рабочего процесса, в котором эксклюзивные блокировки используются для всего .

Answer 1

Если вы привыкли к эксклюзивной блокировке, то трудно принять рабочий процесс edit-merge.

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

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

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

Это не работа системы контроля версий, чтобы помочь с коммуникацией.

Answer 2

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

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

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

Answer 3

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

Одна из этих больших проблем - плохая организация кода. На одном из моих консультационных концертов для крупного оператора связи восемь из тридцати членов команды постоянно работали над одним и тем же исходным файлом (форма «бога» VB.NET). Мы подождем, пока кто-нибудь еще закончит свою работу и снимет эксклюзивную блокировку (VSS), затем следующий человек в порядке кекинга немедленно заблокирует файл, чтобы применить их изменения. Это заняло вечность, потому что они должны были реинтегрировать всю свою работу в новый код, который они могли видеть только тогда. Так как я был новым парнем, я был в нижней части ордера клевания, и мне НИКОГДА не разрешалось проверять изменения моего кода. В конце концов я пошел к менеджеру / директору проекта и предложил мне поручить другую часть функциональности приложения. Этот проект в конечном итоге самоуничтожился, но большинство из нас ушло, когда осознало эту неизбежность. Обратите внимание, что интеграция с VSS также была важной частью этого сбоя, поскольку она вынуждает заблаговременно получить эту ценную блокировку файла.

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

Еще одна из этих больших проблем - перевод бинарных файлов в систему контроля версий. Инструменты контроля версий не предназначены для работы с двоичными файлами, и это хорошо. Двоичные файлы требуют другой обработки, и инструменты контроля версий не могут поддерживать эту специальную обработку. Двоичные файлы должны управляться как единое целое, а не как части (строки). Двоичные файлы имеют тенденцию быть намного более стабильными / неизменными. Двоичные файлы обычно требуют явного управления версиями, отличного от управления версиями исходного кода, часто с несколькими версиями, доступными одновременно. Двоичные файлы часто генерируются из источника, поэтому необходимо контролировать только источник (и сценарии генерации). См. Репозитории Maven для удобного двоичного хранилища (но, пожалуйста, не используйте сам Maven, используйте Apache Ivy).

Answer 4

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

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

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

Тем не менее, я не думаю, что мне нужно снова работать в эксклюзивном мире блокировки.

Answer 5

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

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

С блокировщиком VCS получается, что один человек получает блокировку. Если этот человек заканчивает первым, отлично; если нет, то другой человек может подождать, прежде чем сможет внести изменения. Иногда необходимо быстро исправить ошибку, например, когда кто-то находится в процессе длительного изменения. Как только второй человек получит блокировку, второй человек должен объединить изменения, обычно вручную, и зарегистрировать новую версию. В нескольких случаях я видел, как изменения от первого лица полностью исчезли, так как второй человек не беспокоился о слиянии вручную. Зачастую это слияние делается поспешно, либо из-за отвращения к работе, либо из-за простои времени.

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

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

Answer 6

Аргументы для блокировки действительно плохие. Они в основном говорят: наши инструменты настолько плохи, что не могут слиться, поэтому мы блокируем.

Answer 7

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

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

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

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

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

Модель с открытым исходным кодом (множество людей по всему миру сотрудничают по разным вопросам) продвигает мнение, что блокировка плохая, но она действительно работает для некоторых команд. Это позволяет избежать реальных проблем. Я не говорю, что эти проблемы не могут быть преодолены, но это требует изменения поведения людей; если вы хотите перейти на неблокирующую модель, вы должны убедить их перейти на способ работы, который может показаться им более сложным и может (с их точки зрения) увеличить риск возникновения регрессий.

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

Answer 8

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

• Всегда работать в локальной копии исходного дерева.

• Часто запускайте Windiff по «официальному» коду и, при необходимости, объединяйте изменения в мою локальную копию. Для объединения я использую старый Emacs (Epsilon) и привязываю команду сравнения-буфера к горячей клавише. Другой ключ говорит: «сделайте оставшуюся часть этой строки похожей на ту, что в другом файле», потому что многие изменения небольшие.

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

Итак, когда Fearless Leader говорит: «Вы проверили свой код?» ответ: «Я не проверил».

Но, как я уже сказал, я меньшинство одного.

Answer 9

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

Answer 10

Вот мои $ 0,02.

Блокировка - это старая школа мысли для текстового кодекса. Как только программисты используют слияние несколько раз, они учатся, и, как правило, получают удовольствие от этого.

Действительные случаи для блокировок все еще существуют.

• Графика переделки. В 99% случаев вы не можете объединить 2 человека, работающих над одним и тем же графиком.
• Двоичные обновления.
• Иногда код может быть сложным / достаточно простым, чтобы оправдать одновременную работу только 1 человека. В этом случае для управления проектом необходимо использовать функцию.