Зачем избегать пессимистической блокировки в системе контроля версий? - PullRequest
13 голосов
/ 26 сентября 2008

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

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

Ответы [ 10 ]

14 голосов
/ 26 сентября 2008
  1. Поиграйте с Source Safe и попросите разработчика уехать на две недели в отпуск. Добавьте к этому администраторов VSS, которых нет рядом. Теперь у вас есть исправление для публикации, но вы не можете из-за разработчика
  2. Если у вас есть несколько функций и / или исправлений ошибок, над которыми вы работаете. Неважно, насколько маленький ваш код разбит, у вас все равно будет конфликт за центральный файл.
7 голосов
/ 26 сентября 2008

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

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

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

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

6 голосов
/ 26 сентября 2008
  1. Бобу нужно отредактировать FooBar.java
  2. Джон получил его для редактирования
  3. Боб все равно редактирует свою локальную копию и сохраняет ее как FooBar.java.bak
  4. Когда Джон проверяет его, Боб проверяет его
  5. Боб копирует FooBar.java.bak поверх него и проверяет его в
  6. Джон получает возможность переопределить свою функцию

Я видел, как это происходит снова и снова. Разработчики делают это, потому что этот процесс раздражает:

  1. Бобу нужно отредактировать FooBar.java
  2. Джон извлек его для редактирования
  3. Боб должен подождать, пока он не закончит с Джоном

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

4 голосов
/ 26 сентября 2008
  • У вас не всегда есть возможность разбить файлы на части
    • Файлы конфигурации
    • XML-файлы
  • Даже относительно небольшие файлы могут содержать отдельные части, к которым более одного разработчика требуется доступ
    • Библиотека
    • Утилиты
  • Инструменты слияния намного умнее, чем когда-либо
    • Конфликты довольно редки
  • Уменьшает задержки из-за того, что разработчики "случайно" извлекают файлы
3 голосов
/ 16 апреля 2010

Что касается случая с Бобом и Джоном, кооперативные системы, такие как svn, не предотвращают этот сценарий больше, чем система блокировки. Я могу «обновить» FooBar.java, который удовлетворяет svn тем, что у меня последняя версия, затем удалить этот файл локально и перезаписать его своей собственной личной копией, которую я сделал, не обращая внимания на базовую версию, и проверить это, счастливо уничтожив изменения другого парня. Никакая система, блокирующая или нет, не мешает этому, поэтому я не вижу смысла даже вовлекать ее в дискуссию.

Реальная проблема заключается в определении баланса между

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

Представление о том, что система с блокировкой или без блокировки является «превосходящей», - нонсенс.

Я использовал VSS в режиме полной блокировки по умолчанию с 6 разработчиками, и он работал как мечта. Иногда кто-то может забыть снять блокировку, и нам придется выследить их или сломать замок вручную и слить вручную, когда они вернутся, но это было очень минимально. Я видел, как svn испортил автоматическое слияние несколько раз, так что я не очень доверяю ему. Не всегда помечается «конфликт», когда два человека изменили один и тот же файл так, что их нельзя автоматически объединить.
С другой стороны, я видел, как люди нетерпеливы с замками VSS, редактируют свои собственные копии, и небрежно проверить их поверх кода других людей, и я видел svn ловко ловит меня, когда я могу случайно попытаться проверить что-то, что было изменено кем-то другим с тех пор, как я в последний раз проверял это.

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

3 голосов
/ 26 сентября 2008

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

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

2 голосов
/ 26 сентября 2008

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

Я работал в командах от 2 до 6 человек без блокировки, и у нас никогда не было проблем, за исключением некоторых обычных и необходимых слияний.

Я также однажды работал с блокировкой в ​​ Visual SourceSafe размещенном проекте. ИМХО это было контрпродуктивно.

1 голос
/ 28 сентября 2008

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

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

В противном случае ...

1 голос
/ 26 сентября 2008

если ваши файлы кода настолько велики, что над вами постоянно работают несколько человек одновременно

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

Другими словами, вы будете знать, что «Боб» делает большой набор изменений в компонентах X / Y / Z, если у вас есть исправление ошибки в компоненте X, вам нужно будет поговорить с Бобом, прежде чем пытаться отправить свой изменения.

Как я уже сказал, это идеально;)

1 голос
/ 26 сентября 2008

Разработчики программного обеспечения всегда оптимисты - просто посмотрите на их оценочные навыки!

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...