Почему распределенный контроль версий считается сложнее?

Question

Кажется довольно распространенным (по крайней мере где-то здесь), чтобы люди рекомендовали SVN новичкам для контроля версий, потому что это "проще", чем один из распределенных вариантов. Как обычный пользователь SVN до перехода на Git для многих моих проектов, я обнаружил, что это совсем не так.

Концептуально проще настроить хранилище DCVS с git init (или любым другим), без необходимости настройки внешнего хранилища в случае SVN.

А базовая функциональность между SVN, Git, Mercurial, Bazaar - все по существу идентичные команды для фиксации, просмотра различий и так далее. Это все, что новичок действительно собирается делать.

Небольшая разница в том, как Git требует явного добавления изменений перед их фиксацией, в отличие от политики SVN «все зафиксировать», концептуально проста и, если я не ошибаюсь, даже не проблема при использовании Mercurial или базар.

Так почему же SVN считается проще? Я бы сказал, что это просто неправда.

Answer 1

Если вы используете контроль версий только для себя, SVN, вероятно, сложнее, поскольку установка сложнее. Однако если вы хотите работать с несколькими разработчиками через Интернет, серверный элемент управления имеет преимущества:

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

Answer 2

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

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

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

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

Многие системы, такие как Mercurial, поставляются с полной системой очередей исправлений, а это означает, что с точки зрения непрерывной интеграции вы знаете , что все, что поступает в производство, было одобрено QA. Подобные вещи сложно сделать правильно с CVS или SVN.

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

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

Answer 3

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

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

Answer 4

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

Вся концепция авторазветвления, множественных головок, когда и когда не следует объединять, полностью исключает их, не говоря уже о том, что у них возникают проблемы с освобождением от менталитета «совершить / оформить заказ с $ somecore», который приводит к полной путанице, когда они видят толчки между 2 проверенными копиями.

(Некоторое время возникала проблема, когда кто-то неоднократно сливал 2 ветви, которые не должны были быть объединены, потому что они не могли понять концепцию.)

Однако те же люди, у которых проблемы с распределенной SCMS, заставили меня задать этот вопрос

edit / note Самое большое различие Mercurials, которое я заметил, по сравнению с git, который делает mercurial более трудным для использования для новичков, - это поведение по умолчанию для push / pull, аналогичное выполнению git push --all / git pull - все, что может распространять частные ветки и вносить много путаницы (особенно, когда появляется новая ветка, Mercurial застывает в страхе и спрашивает вас, как справиться с этим, а не просто продолжать грузить), а также разрешение по умолчанию слияния / конфликта инструмент на Mac просто слепит один набор изменений.

Answer 5

Я думаю, что набор инструментов для SVN гораздо шире, поэтому вы могли бы сесть и научить людей (TortoiseSVN, RapidSVN и т. Д.), Даже если у них не было концептуального представления о том, как работает репозиторий. Также относительно легко разместить SVN для вас (например, с trac), не зная ничего. Распределенные еще не получили такой поддержки, и я уверен, что их мнение изменится, когда они это сделают.

Answer 6

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

Answer 7

Я бы сказал, что установка репозитория с DVCS практически проще, но концептуально сложнее. В конце концов, с централизованным VCS пользователи не создают свой собственный репозиторий, они просто создают учетную запись на Assembla или имеют репо для них.

Answer 8

Это плохой маркетинг , все просто. Слишком много вводных DVCS фокусируются на командной строке и говорят: «Ничего себе, разве это не фантастика, вы можете сделать слияние, просто набрав hg merge», совершенно не обращая внимания на тот факт, что многие люди (особенно в Windows) боятся командная строка. Да, Джоэл Спольски, я смотрю здесь свой hginit.com - нам нужна версия TortoiseHg, пожалуйста!

Возможно, это было два года назад, когда у них были плохие реализации GUI, но в последнее время они пошли на дрожжах. TortoiseHg в настоящее время находится в версии 1.0, и, хотя визуально не о чем писать, он довольно прочный, стабильный и простой в использовании. TortoiseGit также очень хорош и отлично справляется со всеми сложностями командной строки git.

Answer 9

Мы изо всех сил стараемся сделать это как можно проще в Codice, но всегда немного сложнее объяснить, конечно, это зависит от аудитории.

Для проектов OSS и небольших групп, особенно людей, работающих на своих ноутбуках и переезжающих туда-сюда, работающих дома, иногда на самолетах и ​​так далее, это довольно легко. Но всякий раз, когда вы разговариваете с корпорациями / предприятиями, они в восторге от его роли в нескольких сайтах, но не настолько, как на первый взгляд. Все зависит от того, есть ли в группе большинство продвинутых разработчиков или нет.