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

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

13
задан raven 26 September 2008 в 16:04
поделиться

10 ответов

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

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

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

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

7
ответ дан Steven Penny 26 September 2008 в 16:04
поделиться
  • 1
    Корректный, я haven' t пересмотрел это приложение в течение очень долгого времени. Но это не работает над более новыми версиями Android; исходная разработка была сделана назад во время 2,2! РЕДАКТИРОВАНИЕ - я верю, хотя тот Google добавил API для захвата этих исходных данных щелчка кнопки гарнитуры намного более легким способом. Попытайтесь искать вокруг это. – JDS 4 July 2013 в 22:54
  1. Bob должен отредактировать FooBar.java
  2. John, проверили его для редактирования
  3. , Bob редактирует свою локальную копию так или иначе и сохраняет ее как FooBar.java.bak
  4. , Когда John проверяет его в, Bob проверяет его
  5. , Bob копирует FooBar.java.bak по нему и проверяет его в
  6. , John добирается, чтобы повторно реализовать его функцию

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

  1. Bob должен отредактировать FooBar.java
  2. John, проверили его для редактирования
  3. , Bob должен ожидать, вертя его ползунки, пока John не сделан

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

6
ответ дан davetron5000 26 September 2008 в 16:04
поделиться
  1. Идут игра с Безопасным Источником и сделали, чтобы разработчик уехал на двухнедельный отпуск. Добавьте к этому администраторов VSS, не являющихся вокруг. Теперь у Вас есть фиксация, которая будет отправлена, но Вы не можете из-за разработчика
  2. , Если у Вас есть несколько функций и/или исправлений ошибок, работающий на. Неважно, как маленький Ваш код разбит, у Вас все еще будет конкуренция для центрального файла.
14
ответ дан Scott Bevington 26 September 2008 в 16:04
поделиться
  • у Вас не всегда есть опция повредить файлы независимо
    • Файлы конфигурации
    • XML-файлы
  • , Даже относительно маленькие файлы могут все еще содержать отличные части, что больше чем одному разработчику нужен доступ к [1 119]
  • Библиотеки
  • Утилиты
    • , Инструменты Слияния намного более умны, чем они когда-либо были
      • , Конфликты довольно редки
    • , Уменьшает задержки из-за разработчиков, имеющих файлы, "случайно" проверил
4
ответ дан pdavis 26 September 2008 в 16:04
поделиться
  • 1
    Потрясающий, обработанный как очарование! – theKing 16 March 2011 в 23:35

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

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

3
ответ дан JeeBee 26 September 2008 в 16:04
поделиться

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

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

я также работал однажды с привязкой Visual SourceSafe размещенный проект. Это было, по моему скромному мнению, контрпродуктивно.

2
ответ дан Peter Mortensen 26 September 2008 в 16:04
поделиться

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

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

1
ответ дан Rob Walker 26 September 2008 в 16:04
поделиться

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

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

Иначе...

1
ответ дан Cody Hatch 26 September 2008 в 16:04
поделиться

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

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

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

, Как я говорю, это идеально;)

1
ответ дан tonylo 26 September 2008 в 16:04
поделиться
  • 1
    @rene: гвоздь #c9721fa0-1cd9-4a21-818c-98d164c9fc14 до конца того адреса и это указывает непосредственно на соответствующий раздел;) – R. Martinho Fernandes 16 February 2011 в 18:31

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

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

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

Представление о том, что либо блокировка, либо отсутствие система запирания "высшая" ерунда.

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

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

3
ответ дан 1 December 2019 в 18:13
поделиться
Другие вопросы по тегам:

Похожие вопросы: