Блокировка контроля версий: вышло ли присяжных?

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

Это не проблема системы управления версиями, которая помогает с сообщением.

Ответ 2

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

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

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

Ответ 3

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

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

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

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

Ответ 6

Здесь мои $0,02.

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

Действующие случаи блокировок все еще существуют.

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

Ответ 7

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

Ответ 8

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

Ответ 9

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

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

  • Запускайте Windiff часто против "официального" кода и при необходимости смените изменения до моей локальной копии. Для слияния я использую старый Emacs (Epsilon) и имею команду compare-buffers, привязанную к горячей клавише. Другой ключ говорит "сделать остальную часть этой строки, как и в другом файле", потому что многие изменения невелики.

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

Итак, когда Бесстрашный Лидер говорит: "Вы проверили свой код?" ответ: "У меня нет никаких проверок".

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

Ответ 10

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

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

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

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

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

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

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

Ответ 11

Адресация ваших комментариев редактирования.

Даже RCS и SCCS (дедушка VCS для большей части того, что работает в Unix/Linux в эти дни) позволяют одновременное редактирование доступа к файлам, и я не имею в виду отдельные ветки. С помощью SCCS вы можете сделать "get -k SCCS/s.filename.c" и получить редактируемую копию файла - и вы можете использовать опцию ('-p' IIRC), чтобы получить ее на стандартный вывод. Вы могли бы заставить других людей сделать то же самое. Затем, когда пришло время регистрации, вам нужно было убедиться, что вы начали с правильной версии или сходили, чтобы иметь дело с изменениями, так как ваша стартовая версия была собрана и т.д. И ни одна из этих проверок не была автоматизирована, и конфликты не обрабатывались или не маркировались автоматически, и так далее. Я не утверждал, что это было легко; просто чтобы это можно было сделать. (В соответствии с этой схемой блокировки будут удерживаться на короткое время, пока выполняется проверка/слияние. У вас есть блокировки по-прежнему - SCCS требует их, а RCS может быть скомпилирован с строгой блокировкой - но только для коротких замыканий, но это тяжелая работа - никто не делал этого, потому что это такая тяжелая работа.)

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

Мне все равно нравится блокировка. Основная рабочая система, которую я использую (IBM Rational) Atria ClearCase; для моего собственного развития я использую RCS (отказавшись от SCCS вокруг Y2K). Оба используют блокировку. Но у ClearCase есть хорошие инструменты для слияния, и мы делаем немало этого, не в последнюю очередь потому, что на продукте, над которым я работаю (по 4 основные версии), есть не менее 4-х кодовых строк. И исправления ошибок в одной версии довольно часто применяются к другим версиям почти дословно.

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

Ответ 12

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

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

Если вам нужно управлять версиями двоичным файлом, вам нужна некоторая форма блокировки, чтобы предотвратить или, по крайней мере, предупредить, случайную перезапись. Это должна быть фундаментальная особенность любого VCS, даже распределенного. Чтобы использовать такую ​​функцию в DVCS, может потребоваться создание центрального хранилища, но настолько ли это зло? Если вы используете DVCS в любой корпоративной среде, у вас будет центральный репо для обеспечения непрерывности бизнеса.