Многим программистам, использующим Visual Studio, трудно приспособиться к тому факту, что в других системах управления версиями файлы не нужно блокировать / передавать одному разработчику в любой момент времени.
Сторонники слияния говорят, что разрешение двум людям работать над одним и тем же файлом увеличивает производительность, поскольку устраняет необходимость в очереди за одним и тем же исходным файлом. Это также позволяет избежать случаев, когда код должен быть написан, но исходный код передан парню, который только что уехал в двухнедельный отпуск.
Сторонники блокировки говорят, что возникает большой риск, когда над одним файлом одновременно работают несколько человек. По их словам, общение и координация между членами команды становятся гораздо более необходимыми при использовании модели слияния. Кроме того, многие люди не доверяют автоматическим слияниям.
Какая самая веская причина использовать один метод вместо другого?
Блокировка файлов может не очень хорошо масштабироваться для более крупной команды. С системами управления версиями, которые используют много ветвлений и слияний, может быть просто нецелесообразно позволять кому-либо одному давать такой контроль над репозиторием (таким образом, не масштабироваться для более крупной команды).
В Subversion, например, ветвление представляет собой копию указателя, поэтому вы можете легко создать ветвь TRY, чтобы не повредить магистраль, если вы с чем-то экспериментируете, но хотите зафиксировать.
В распределенных системах контроля версий, таких как Git, каждая проверка по сути является ветвью.
Перейдя от заблокированной модели к модели слияния, сделаю следующие наблюдения:
Модель слияния IMHO намного лучше, потому что она дает мне свободу при работе с кодом. Возможно, это не лучшая модель для «потемнения» с кодом на 1 неделю, но опять же, для модели «блокировки» это не менее большая проблема. Никто не должен отказываться от кода в течение недели.
Слияния хороши. Программисты, работающие над одним и тем же файлом, в любом случае должны общаться. Если они НЕ общаются, в этом коде есть более серьезные проблемы.
Слияние - это естественный способ делать что-то, оно приносит дисциплину, экономит время (представьте, что оба программиста завершают рефакторинг одного и того же кода).
Блокировка является реактивной ... слияние проактивно ...
Я также считаю, что слияние лучше, но я бы сказал, что блокировка является проактивной (вы блокируете заранее), а слияние является реактивным (вы объединяетесь после внесения изменений).
Maverique, я полагаю, можно также утверждать, что ваша ситуация с двумя программистами, реорганизующими один и тот же код, может быть предотвращена путем использования блокировки, а не слияния.
Я не могу понять, как слияние экономит время, учитывая ваш пример - «представьте, что оба программиста завершают рефакторинг одного и того же кода» - для меня это звучит так, как будто вы дублируете работу. Вы можете уточнить?
Модель блокировки предотвращает возникновение проблемы. Когда второй программист подумает о рефакторинге кода, он увидит, что он заблокирован. Затем они понимают, что двум программистам нужно поговорить. Согласно модели слияния, оба программиста могут работать над своими локальными копиями, прежде чем они поймут, что существует необходимость в общении. Коммуникация является ключевым элементом любой разработки, и можно утверждать, что блокировка способствует коммуникации.
Я думаю, что модель слияния намного лучше, она более гибкая, пользователи могут работать параллельно, никогда не дожидаясь друг друга, а время, необходимое для разрешения конфликтов, намного меньше, чем время, потерянное моделью блокировки. В большинстве случаев изменения, внесенные в файл, не конфликтуют и могут быть автоматически объединены.
Вероятно, поэтому это модель по умолчанию в большинстве современных систем управления версиями.
Но, в конце концов, критическим фактором всегда является общение с пользователем. Когда пользователи плохо общаются, конфликты наверняка возрастут.
Распространенная жалоба на блокировку VCS заключается в том, что у вас возникает проблема, когда кто-то уезжает в отпуск или на конференцию, оставляя некоторые файлы заблокированными :)
А затем администратор снимает блокировку, и остальная команда продолжает. Человек, который не соблюдает правила этикета, должен иметь дело с приведением своей работы в норму.
Слияние - правильный подход, но, чтобы добавить к предыдущему ответу, он должен соответствовать нескольким критериям, чтобы быть эффективным.
Кроме того, имейте в виду, что существует возможность сочетания обоих:
В этом случае вы должны убедиться, что существует механизм «выпуска», чтобы избежать блокировки первым разработчиком.
Защитники блокировки ошибаются, если есть такой человек, который защищает это. Каждая команда, с которой я встречался, использующая старомодную систему блокировки, жаловалась на нее и с тоской смотрела на людей, использующих другие методы. Я работал над проектом для одного места, которое было вынуждено использовать систему блокировки, и решил вообще не использовать КОНТРОЛЬ (поэтому я создал ветку секрет SVN, хотя я предпочитаю Bzr или Git).
Итак, я подозреваю, что единственные «защитники блокировки» - это сотрудники отдела маркетинга системы запирания.
Не правда. Я работаю с несколькими из них. Я пытаюсь отключить нашу группу от SourceSafe, но одним большим камнем преткновения является то, что вся группа здесь привязана к модели заблокированных касс. Слияния здесь страшнее, чем талибы.
... Думаю, я должен также отметить, что эта группа глубоко консервативна. Мы только сейчас начинаем отказываться от VC++ 6.0.
хммм, тогда я думаю, люди боятся того, чего они не знают. Если вы попытаетесь слить, вы никогда не вернетесь к блокировке
Я сам очень боялся идеи слияния, имея воспоминания о кошмарах, пытающихся слить код еще в 80-х. Однако я загрузил Subversion и Git, немного поиграл с ними и впечатлен их обещаниями. Жаль, что я здесь единственный.
Я сделал одну вещь, которую вы можете попробовать: следить за собой. Поскольку модель блокировки более пессимистична, это легко сделать, если вы работаете в рамках этой модели. Каждый раз, когда у вас возникает конфликт блокировки с другим разработчиком, подойдите к нему и поговорите с ним. Следите за следующим:
4 - единственная ситуация, когда можно утверждать, что блокировка вам помогла, и покрывает каждый такой случай. За последние 3 года я обнаружил, что почти все проблемы относятся к категории 1-3. Я думаю, что нашел 4 однажды. Но если я сложу все проигранное время до 1–3, это потрясающе.
Модель слияния похожа на плавание. Люди, которые сначала этого не делали, этого боятся, но все, кто умеет это делать, любят. У некоторых людей на раннем этапе есть плохой опыт, и большинству людей просто нужно испытать его и преодолеть этот первоначальный страх.
Самые большие проблемы слияния, с которыми я когда-либо сталкивался, были на сайте, где у нас был блокируемый контроль версий (SCCS, если быть точным - это было некоторое время назад).
Что произойдет, если человек А будет над чем-то работать и получит файл. Человек B получит срочную просьбу исправить что-то для клиента и должен будет изменить этот файл.
Это происходило по-разному. Иногда A возвращался, B вносил изменения, а затем A продолжал работать с рабочей копией A и стирал изменения B. Иногда B начинал работать с скопированной копией, поскольку время имело существенное значение, и изменения могли занять некоторое время, чтобы получить правильные и перезаписать изменения A. Иногда изменения B будут взаимодействовать с изменениями A, и некоторые изменения A будут искажены или потеряны. В последнем случае предупреждения не последовало.
При объединении VCS A и B вносят свои изменения, и система следит за тем, чтобы ничего не потерялось. В последнем случае VCS фиксирует конфликт, поэтому он не будет пропущен.
Также была проблема с внесением более значительных изменений в программный файл, так как это могло быть прервано необходимыми исправлениями, что значительно усложняло завершение.
Я никогда не видел производственной среды, в которой можно было бы гарантировать, что двум людям не придется работать над одним и тем же файлом примерно в одно и то же время. С этой ситуацией хорошо справляется слияние VCS. Блокировка VCS - нет.
Слияние всегда проблематично и контрпродуктивно, и его следует избегать любой ценой. Слияние больших изменений кода и файлов, подвергшихся рефакторингу, является проблемой. Принуждать всех разработчиков к модели оптимистической блокировки неправильно.
Здесь есть хороший момент. Крупные изменения кода и рефакторинг ДОЛЖНЫ выполняться исключительно и, если возможно, всей командой, сидящей вместе. Но для повседневной работы блокировка - это просто трата времени.
-1 за ответ без аргументов. Вы делаете заявления, но не хотите объяснять. Я провел огромный рефакторинг в модели слияния без особых проблем. Ключ - частая синхронизация.
@tishma Большой рефакторинг отлично работает без блокировок, если ваша VCS хорошо поддерживает ветвление и слияние. (Я прошел через рефакторинг нескольких кодовых баз с использованием Git, который не блокируется. Это не было проблемой.)
@ MarnenLaibow-Koser Верно. Дело в том, что слияние независимых изменений кода, подвергшегося серьезному рефакторингу, почти наверняка не окажется тривиальным. В определенной степени Git может помочь, и все зависит от того, насколько две ветки в конечном итоге расходятся друг от друга.
Думаю, это зависит от случая. Вы бы взяли самолет, если бы знали, что файлы, управляющие самолетом, были одновременно изменены многими людьми, а затем объединены?
В глупых приложениях можно использовать подход слияния, но если мы говорим о серьезных системах ... таких как банковские системы и т. Д ...
«Вы бы взяли самолет, если бы знали, что файлы, управляющие самолетом, были изменены одновременно многими людьми, а затем слиты?» Конечно, если бы у них был разумный процесс, гарантирующий, что ошибки не будут внесены. Рабочие процессы слияния используются для критических систем; они не должны быть проблемными.
Там, где я нахожусь, у нас есть настраиваемый (кашляющий) слой поверх SourceSafe, который блокируется по проекту! Плакать...