Зачем избегать пессимистической блокировки в системе контроля версий?

Ответ 1

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

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

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

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

Ответ 2

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

Ответ 3

• Бобу нужно редактировать FooBar.java
• Джон проверил это для редактирования
• Боб все равно редактирует свою локальную копию и сохраняет ее как FooBar.java.bak
• Когда Джон проверяет его, Боб проверяет его
• Боб копирует FooBar.java.bak поверх него и проверяет его в
• Джон получает возможность реализовать свою функцию

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

• Бобу нужно редактировать FooBar.java
• Джон проверил это для редактирования
• Боб должен подождать, покачивая большими пальцами, пока Джон не закончит.

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

Ответ 4

• У вас не всегда есть возможность разбивать файлы отдельно
  • Файлы конфигурации
  • Файлы XML
• Даже относительно небольшие файлы могут содержать отдельные части, которым требуется более одного разработчика
  • Библиотеки
  • Утилиты
• Слияние инструментов намного умнее, чем когда-либо
  • Конфликты довольно редки.
• Сокращает задержки из-за того, что разработчики имеют файлы "случайно".

Ответ 5

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

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

Ответ 6

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

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

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

Понятие о том, что либо блокирующая, либо неблокирующая система является "высшей", является бессмыслицей.

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

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

Ответ 7

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

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

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

Ответ 8

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

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

Ответ 9

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

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

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

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

Ответ 10

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

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

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