Блокировка ревизионного контроля: жюри все еще отсутствует?
Когда я в сети, кажется, все согласились с тем, что использование эксклюзивного рабочего процесса блокировки в управлении исходным кодом - плохая вещь. Все новые системы контроля версий, которые я вижу, созданы для редактирования и объединения рабочих процессов, и многие даже не поддерживают эксклюзивные блокировки.
Однако все, с кем я работаю, считают, что эксклюзивные блокировки необходимы для любой системы контроля версий, и работа любым другим способом была бы кошмаром. Даже недавние наемы от других компаний, кажется, приходят с этой идеей.
Мой вопрос не в том, кто прав. Я почти уверен, какой ответ я получу на это. Мой вопрос заключается в том, есть ли еще споры по этому вопросу? Есть ли честный лагерь "про-блокировки", который делает серьезное дело? Проводится ли какая-либо работа по продвижению искусства контроля версий, основанного на модели блокировки? Или блокирующие вентиляторы порют мертвую лошадь?
РЕДАКТИРОВАТЬ: ответы до сих пор сделали хорошую работу, объясняя, почему эксклюзивные блокировки являются хорошей функцией, чтобы иногда использовать. Тем не менее, я говорю о продвижении рабочего процесса, где эксклюзивные блокировки используются для всего.
12 ответов
Если вы привыкли к эксклюзивной блокировке, тогда трудно охватить рабочий процесс edit-merge.
Эксклюзивная блокировка имеет свои преимущества, особенно для двоичных файлов (изображений, видео и т. Д.), Которые не могут быть объединены автоматически или не объединены вообще.
Но: необходимость исключительной блокировки всегда указывает на другую проблему: хорошее общение между людьми, работающими над проектом. Эксклюзивная блокировка обеспечивает плохую замену: она сообщает пользователям, что кто-то уже работает над этим конкретным файлом - что они должны знать, не используя систему контроля версий.
Поскольку существуют лучшие способы помочь в общении между членами команды, большинство (всех?) Систем контроля версий больше не реализуют эксклюзивную блокировку или просто сокращенную версию (т. Е. Блокировку, но такую, что эти блокировки не применяются).
Это не работа системы контроля версий, чтобы помочь с коммуникацией.
Мне нравится иметь возможность эксклюзивной блокировки некоторых файлов [s].
Наличие эксклюзивной блокировки необходимо, например, для двоичных файлов.
Это также частично необходимо для некоторых сгенерированных компьютером недвоичных файлов (например, для файлов проекта Visual Studio, которые вообще не "сливаются", если когда-либо есть два параллельных изменения, которые должны быть объединены).
Если вы считаете, что слияния сложны (и хотя мы прошли долгий путь, они могут быть в некоторых обстоятельствах), и у вас нет программистов, часто желающих редактировать один и тот же файл, эксклюзивная блокировка не обязательно так уж плоха.
Я бы не стал использовать их в проекте с открытым исходным кодом, но в корпоративном мире, где правила строже, и вы можете подойти к парню и сказать: "Могу ли я сломать ваш замок?", Он дает представление о том, кто такие люди. работает и избегает конфликтов, поэтому их не нужно решать позже.
Если двум людям действительно нужно работать с файлом одновременно, часто вы можете разветвлять этот файл, и, пока инструмент дает понять, что эту ветвь необходимо объединить обратно, вы можете сделать это и разрешить любые конфликты, а затем,
Тем не менее, я не думаю, что хочу снова работать в эксклюзивном мире блокировки.
Эксклюзивная блокировка - лучшее, что вы можете сделать в худшем случае, поэтому ее наличие всегда говорит мне, что есть большие проблемы.
Одна из этих больших проблем - плохая организация кода. На одном из моих консультационных выступлений для крупного оператора связи восемь из тридцати членов команды постоянно работали над одним и тем же исходным файлом (форма "бога" VB.NET). Мы подождем, пока кто-нибудь еще закончит свою работу и снимет эксклюзивную блокировку (VSS), затем следующий человек в порядке кекинга немедленно заблокирует файл, чтобы применить их изменения. Это заняло вечность, потому что они должны были реинтегрировать всю свою работу в новый код, который они могли видеть только тогда. Так как я был новым парнем, я был в нижней части ордера клевания, и мне НИКОГДА не разрешалось проверять изменения моего кода. В конце концов я пошел к менеджеру / директору проекта и предложил мне поручить другую часть функциональности приложения. Этот проект в конечном итоге самоуничтожился, но большинство из нас ушло, когда осознало эту неизбежность. Обратите внимание, что использование интеграции VSS также было важной частью этого сбоя, так как оно вызывает раннее приобретение этой драгоценной блокировки файлов.
Таким образом, хорошо организованный проект почти никогда не должен приводить к тому, что два человека работают над одной и той же частью одного и того же исходного файла одновременно. Поэтому нет необходимости в эксклюзивной блокировке.
Еще одна из этих больших проблем - перевод бинарных файлов в систему контроля версий. Инструменты контроля версий не предназначены для работы с двоичными файлами, и это хорошо. Двоичные файлы требуют другой обработки, и инструменты контроля версий не могут поддерживать эту специальную обработку. Двоичные файлы должны управляться как единое целое, а не как части (строки). Двоичные файлы имеют тенденцию быть намного более стабильными / неизменными. Двоичные файлы обычно требуют явного управления версиями, отличного от управления версиями исходного кода, часто с несколькими версиями, доступными одновременно. Двоичные файлы часто генерируются из источника, поэтому необходимо контролировать только источник (и сценарии генерации). См. Репозитории Maven для бинарного дизайна хранилища (но, пожалуйста, не используйте сам Maven, используйте Apache Ivy).
Аргументы для блокировки действительно плохие. Они в основном говорят: наши инструменты настолько плохи, что не могут слиться, поэтому мы блокируем.
По моему опыту, часто необходимо, чтобы два человека работали над одним файлом одновременно. (Есть, предположительно, магазины, где этого не происходит, но у меня достаточно разнообразный опыт, чтобы опираться на него.)
В этих случаях обоим людям необходимо получить копии оригинала, выполнить свою работу и объединить свои изменения. В неблокирующих VCS это делается по большей части автоматически и точно.
С блокировкой VCS происходит то, что один человек получает блокировку. Если этот человек заканчивает первым, отлично; если нет, то другой человек может подождать, прежде чем сможет внести изменения. Иногда необходимо быстро исправить ошибку, например, когда кто-то находится в процессе длительного изменения. Как только второй человек получит блокировку, второй человек должен объединить изменения, обычно вручную, и зарегистрировать новую версию. В нескольких случаях я видел, как изменения от первого лица полностью исчезли, так как второй человек не беспокоился о слиянии вручную. Зачастую это слияние делается поспешно, либо из-за отвращения к работе, либо из-за нехватки времени.
Поэтому, если два человека должны работать над одним файлом одновременно, неблокирующая VCS почти всегда лучше.
Если этого не происходит, и двум людям никогда не нужно работать над одним файлом одновременно, не имеет значения, какой вы используете.
На мой взгляд, главная причина, по которой люди используют эксклюзивную блокировку, - это ее простота и отсутствие риска.
Если у меня есть эксклюзивный доступ к файлу, мне не нужно будет пытаться понять, что кто-то другой внесет изменения в тот же файл. Мне не нужно рисковать внесением изменений, а затем объединяться с кем-то еще, когда я регистрируюсь.
Если у меня есть эксклюзивная блокировка для файлов, которые я изменяю, то я знаю, что когда я вернусь, я смогу проверить целостность изменений; мне проще сделать это.
Другим аспектом слияния (особенно автоматическим слиянием) является возможность возникновения проблем регрессии. Без хороших автоматических тестов, каждый раз, когда вы выполняете автоматическое слияние, у вас могут возникнуть проблемы. По крайней мере, если у вас есть эксклюзивная блокировка чего-либо, вы гарантируете, что кто-то просматривает код, прежде чем он будет зарегистрирован. Для некоторых это снижает риск.
Что исключает исключительную блокировку, так это потенциальный параллелизм изменений. Вы не можете иметь двух человек, работающих над файлом.
Модель с открытым исходным кодом (многие люди по всему миру сотрудничают по разным вопросам) продвигают мнение, что блокировка плохая, но она действительно работает для некоторых команд. Это позволяет избежать реальных проблем. Я не говорю, что эти проблемы не могут быть преодолены, но это требует изменения поведения людей; если вы хотите перейти на неблокирующую модель, вы должны убедить их перейти на способ работы, который может показаться им более сложным и может (с их точки зрения) увеличить риск возникновения регрессий.
Лично я предпочитаю не использовать замки, но я понимаю, почему некоторым людям это не нравится.
Интересный вопрос. Для меня проблема не столько в блокировке, сколько в блокировке. В этом магазине я меньшинство, потому что мне нравится сливаться. Мне нравится знать, что другие люди сделали с кодом. Итак, что я делаю:
Всегда работайте в локальной копии исходного дерева.
Часто запускайте Windiff по "официальному" коду и, при необходимости, объединяйте изменения в мою локальную копию. Для объединения я использую старый Emacs (Epsilon) и привязываю команду сравнения-буфера к горячей клавише. Другой ключ говорит: "сделайте оставшуюся часть этой строки похожей на ту, что в другом файле", потому что многие изменения невелики.
Когда я буду готов проверить изменения, Windiff сообщит мне, какие файлы мне нужно заблокировать, зарегистрировать и разблокировать. Поэтому я держу их запертыми как можно меньше времени, например, минут.
Поэтому, когда Fearless Leader говорит: "Вы проверили свой код?" Ответ: "Я не проверил".
Но, как я уже сказал, я меньшинство одного.
В проекте с открытым исходным кодом, таком как игра, имеет смысл держать изображения под контролем ревизии, и их приятно иметь возможность блокировать (Subversion поддерживает это). Для исходных файлов лучше войти в рабочий процесс edit-merge. Это не сложно и повышает производительность в моем опыте.
Вот мои $0,02.
Блокировка - это старая школа мысли для текстового кодекса. Однажды программисты используют слияние пару раз, они учатся, и обычно им нравится сила этого.
Действительные случаи для блокировок все еще существуют.
- Графические изменения. 99% времени вы не можете объединить 2 человека, работающие на одном графике.
- Двоичные обновления.
- Иногда код может быть сложным / достаточно простым, чтобы оправдать работу только 1 человека за раз. В этом случае это выбор управления проектом.
Немного опоздал к этому обсуждению, но для всех, кто читал и переваривал написание твердого кода Стива Магуайра, главное, чтобы ваши инструменты выявляли и идентифицировали как можно больше проблем.
Компилятор не устает после 12 или более часов подряд и забывает выдавать синтаксическую ошибку. Но довольно легко забыть ручной шаг - инициировать общение и заплатить за него позже.
Если вам нужен контроль версий двоичного файла, вам нужна некоторая форма блокировки, чтобы предотвратить - или хотя бы предупредить - случайную перезапись. Это должно быть фундаментальной особенностью любой VCS, даже распределенной. Для использования такой функции в DVCS может потребоваться создание центрального хранилища, но разве это так плохо? Если вы используете DVCS в любой корпоративной среде, у вас будет центральное репо для обеспечения непрерывности бизнеса.
Обращаясь к вашим комментариям редактирования.
Даже RCS и SCCS (дедушка VCS для большей части того, что в наши дни работает на Unix/Linux) разрешают одновременный доступ к редактированию файлов, и я не имею в виду отдельные ветви. С SCCS вы могли бы сделатьget -k SCCS/s.filename.c'и получите редактируемую копию файла - и вы можете использовать опцию ('-pIIRC), чтобы получить его на стандартный вывод. Вы могли бы, чтобы другие люди делали то же самое. Затем, когда пришло время для регистрации, вам нужно будет убедиться, что вы начали с правильной версии или выполнить слияние для изменения с момента сбора вашей начальной версии и т. Д. И ни одна из этих проверок не была автоматизирована, и конфликты не обрабатывались и не отмечались автоматически и т. д. Я не утверждал, что это было легко; просто это можно было сделать. (Согласно этой схеме блокировки будут удерживаться только в течение короткого времени, пока выполняется проверка / слияние. У вас все еще есть блокировки - SCCS требует их, и RCS может быть скомпилирована с обязательной строгой блокировкой - но только для кратковременной блокировки. продолжительности работы. Но это тяжелая работа - никто не делал этого, потому что это такая тяжелая работа.)
Современные VCS решают большинство проблем автоматически или почти автоматически. В этом их огромная сила по сравнению с системами предков. А поскольку объединение является простым и почти автоматическим, оно допускает разные стили разработки.
Я все еще люблю блокировку. Основной рабочей системой, которую я использую, является (IBM Rational) Atria ClearCase; для собственного развития я использую RCS (отказавшись от SCCS около 2000 года). Оба используют блокировку. Но у ClearCase есть хорошие инструменты для слияния, и мы делаем это немало, не в последнюю очередь потому, что в продукте, над которым я работаю, есть по крайней мере 4 кодовых линии (то есть 4 основных версии). И исправления ошибок в одной версии довольно часто применяются к другим версиям, почти дословно.
Таким образом, VCS только для блокировки обычно не имеет достаточно хороших средств слияния, чтобы поощрять использование одновременного редактирования файлов. Более современные VCS имеют лучшие средства слияния (а также ветвления) и, следовательно, не так сильно нуждаются в блокировке для более чем кратчайшего срока (достаточного для того, чтобы операции над файлом - или файлами в более продвинутых системах - были атомарными).,