MCP

воскресенье, 6 ноября 2011 г.

SVN vs DVCS

Последнее время, появилось множество фанатов, орущих про то, что SVN — сраное говно, а Git/Mercurial — активно рулят. При этом, несмотря на плюсы распределённых систем, у них ещё дофига минусов, которые решаются или костылями, или инструкциями по работе, или надеванием штанов через голову, потому что "это модно".

Покопавшись в интернете, я не нашёл особых статей со сравнением DVCS (распределённых системы управления версиями) и SVN (хотя не сильно-то и искал), так что решил написать свою, чтобы Трухин Юрий посмеялся. 
Собственно, буду сравнивать концепцию DVCS (без сильных завязок на Git или Mercurial) и SVN, как одного из самых ярких представителей централизованных систем (TFS тоже яркий, но это комбайн с кучей бантиков и практически только под Visual Studio)

Всё нижеперечисленное, моё личное мнение, которое может не совпадать с мнением фанатов какой-либо системы, да и вообще быть ошибочным.

Начнём с плюсов DVCS:
  • У каждого своя пользователя копия репозитория в которой он может делать всё что угодно, до заливки в основной репозиторий
  • Удобные бранчи и теги 
  • Более приличный мёрж (за счёт ченджсетов)
  • Отличная автономность
  • Возможность устраивать сложную систему иерархий в организации проекта
А теперь, про недостатки, про то, что не пишут или что обходится административными мерами:
  • Один репозиторий — один проект. Т.е. распределённые системы удобны для работы над одним проектом, и очень плохо разделять зону ответственности между связанными проектами. Технически, два независимых проекта, это два полностью независимых проекта, с разными репозиториями и отсутствием общей инфраструктуры
  • Подключение к проекту внешних модулей (например, общей между разными проектами, библиотеки). В svn это весьма коряво решается через svn:externals, и в git и в mercurial есть ещё более корявые решения, но в принципе решить задачу можно, хоть и очень коряво.
  • Проблема с хранением больших бинарных файлов (особенно, если они ещё и изменяются периодически). Т.к. у каждого разработчика по копии своего репозитория, то у каждого по копии всех этих файлов (и всей истории), даже если они ему и не нужны. Решение — использовать всяческие расширения или выносить эти файлы из DVCS в другие системы (например, тот же SVN).
  • Невозможность забрать всего-лишь несколько файлов из проекта. Например, менеджерам абсолютно не нужен код, им нужно только ТЗ, макеты и прочая мелочёвка. При этом, уровень грамотности у них в плане работы с VCS значительно ниже. В общем, как результат, проще документацию хранить отдельно, чем обучать менеджеров работе с DVCS.
  • Отсутствие единой сквозной нумерации. Прощай автоверсионирование в билдах и удобная привязка к багтрекеру. Проблема некритичная, но очень "радует" своим удобством.
  • Отсутствие возможности тонкого разграничения прав, например, запретить писать некоторым пользователям в важные конфигурационные файлы, или же заблокировать от изменений часть проекта.
  • Отсутствие возможности блокировки файлов. Фича редкая, но когда нужна, тогда без неё плохо. Можно обойти административными мерами, но их любят нарушать.
  • Практически всегда необходимо выделять центральный репозиторий (хотя бы для автомтатических билдов), как результат, он выполняет роль сервера SVN, т.е. в принципе, всё сводится назад, к централизованной системе с более умными клиентами у разработчиков.
  • Хуки на определённые группы файлов, и вообще слежение за изменениями. Необходимо прилагать дополнительные усилия для слежки, то, что в SVN делается из коробки.
  • Потеря исходников автоматически означает потерю всего репозитория, т.е. включает в себя всю историю, уже удалённые файлы, даты, список пользователей, ветвления. Т.е. ценность данной информации гораздо выше, стоимость потери — тоже. А с учётом пункта об проблемах с разграничением прав, всё становится совсем плохо. А потерять один ноутбук разработчика гораздо проще чем данные с одного сервера, охраняемого злобным цербером администратором. 
И как закономерный результат: отлично DVCS применимы для распределённой разработки (как и следует из их названия) и слабо применимы для локальной группы разработчиков, когда все преимущества распределённости теряются, а недостатки никуда не деваются.

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

В-общем, мое мнение: DVCS нужно засунуть туда, куда они пришли, в распредённость, и не иметь проблем с ними, если не видно явного преимущества в данный момент. Ведь из SVN всегда можно сделать экспорт в другую систему, когда это понадобится. А вот обратно — уже никак, и от проблем DVCS уже никуда не получится деться.

17 комментариев:

  1. Хм. да. Таки Вы абсолютно правы.
    В принципе, для распределенных проектов (может быть) гит чем-то лучше, но только сильно ли много таких проектов? А централизованный сервер - обслуживать проще, бэкапить - проще, даже если прогер и провтыкает где-нить код/ноут и т.д., то его брэнчи никуда не денутся. Можно даже предусмотреть такую возможность изначально - добавить папку типо /branches/user_name/, дать прогеру права говнякать в папке, и, в принципе, все...

    ОтветитьУдалить
  2. Я конечно не гуру в вопросе о том что лучше CVCS или DVCS но раз уж вы хотите действительно показать минусы DVCS и плюсы CVCS то следовало бы лучше изучить вопрос, и самостоятельно протестировать хотя-бы двух главных представителей DVCS (Mercurial и Git) на сегоднешний момент. И обязательно посмотрите выступлени Линуса Торвальдса про свою систему Git если не видели.
    На данный момент я пишу курсовую на тему Изучение VCS Mercurial, где необходимо также изучить плюсы и минусы CVCS и DVCS.

    ОтветитьУдалить
  3. arenoros, это комментарий и разряда Сперва добейся?. Я рад за вас, что вы пишите курсовую, но хотелось бы всё-таки аргументов более относящихся к статье :)

    ОтветитьУдалить
  4. распределённые системы удобны для работы над одним проектом, и очень плохо разделять зону ответственности между связанными проектами.
    -----------
    Расскажите это разработчикам таких монстров, как Qt, GNOME, KDE, kernel к примеру. А то они об этом не знают

    Подключение к проекту внешних модулей
    -----------
    Сами пишете, что и в svn это коряво. Казалось бы, причем тут DVCS???

    Проблема с хранением больших бинарных файлов (особенно, если они ещё и изменяются периодически). Т.к. у каждого разработчика по копии своего репозитория, то у каждого по копии всех этих файлов (и всей истории), даже если они ему и не нужны.
    ---------------
    Автор, ну осильте наконец-то git submodule. Субмодули можно клонировать, можно выборочно клонировать и можно не клонировать.

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

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

    Отсутствие возможности тонкого разграничения прав
    ---------------
    Изучайте gitosys

    Отсутствие возможности блокировки файлов
    ---------------
    Этого так да, нет. Было бы неплохо, чтобы Вы рассказали, в каких "редких" случаях это необходимо.

    Практически всегда необходимо выделять центральный репозиторий (хотя бы для автомтатических билдов), как результат, он выполняет роль сервера SVN, т.е. в принципе, всё сводится назад, к централизованной системе с более умными клиентами у разработчиков.
    ---------------
    Простите, но это полная чепуха. Можно лишь посоветовать все-таки попытаться вникнуть в идеологию git.

    Хуки на определённые группы файлов, и вообще слежение за изменениями.
    ---------------
    В Mercurial, я так понимаю, это есть.

    Потеря исходников автоматически означает потерю всего репозитория, т.е. включает в себя всю историю, уже удалённые файлы, даты, список пользователей, ветвления.
    ---------------
    Тогда давай те рассмотрим ситуацию, когда навернулся сервак с репой svn. Вот это действительно потеря ВСЕГО. В отличии от.

    ОтветитьУдалить
  5. Расскажите это разработчикам таких монстров, как Qt, GNOME, KDE, kernel к примеру. А то они об этом не знают
    В данных проектах плюсы по возможности удалённой разработке перевешивают остальные недостатки.


    Сами пишете, что и в svn это коряво. Казалось бы, причем тут DVCS???
    В них всё ещё хуже

    Автор, ну осильте наконец-то git submodule. Субмодули можно клонировать, можно выборочно клонировать и можно не клонировать.
    Ну да, костыль придумали, жить-то как-то надо.

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

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

    Изучайте gitosys
    gitosis? Впрочем, опять же, если делать 100500 репозиториев, то это будет решением.

    Этого так да, нет. Было бы неплохо, чтобы Вы рассказали, в каких "редких" случаях это необходимо.
    Защита от изменения конфигов, как вариант. Иногда бывает работа с документацией и прочие глобальные изменения, когда явно надо запретить что-то изменять. Впрочем, как всегда можно всё это вынести в очередной репозиторий или обвешаться хуками.

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


    Хуки на определённые группы файлов, и вообще слежение за изменениями.
    ---------------
    В Mercurial, я так понимаю, это есть.

    Да, есть. Сейчас не помню, что именно имел ввиду, или удалю или детализирую данный пункт позднее.

    Тогда давай те рассмотрим ситуацию, когда навернулся сервак с репой svn. Вот это действительно потеря ВСЕГО. В отличии от.
    Когда-то давно были придуманы бекапы. Очень полезная вещь, рекомендую!

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

    Ну да, 100500 репозиториев по десятку файлов, это очень удобно и очевидно.
    ---------------
    Наверное удобнее и очевиднее держать одного монстра с 100500 подпроектами. И каждому менеджеру, дизайнеру итд рассказывать где, какие и в каком количестве брать файлы. Вместо того, того, чтобы сказть:"Вот твоя репа". Я правильно Вас понял?

    Ну да, хеш очень нужная информация главное понятная и очевидная. По нему сразу видно, когда и кем сделан билд и какие изменения в него вошли. А если сравнить два хеша, то вообще можно даже прикунить дифф в голове.
    ---------------
    По хэшу сразу видно, когда и кем сделан коммит. Вам это не известно? К тому же можно использовать первые шесть знаков. И чем Вам diff то не нравиться? В git-е как-раз он, этот diff зело крут. Заодно расскажите, сколько времени в svn занимает сравнение хранилища с хранилищем.

    gitosis? Впрочем, опять же, если делать 100500 репозиториев, то это будет решением.
    ---------------
    Извиняюсь, очепятка. gitolite. И это решение, как для одной репы, так и для 100500 репов. :)

    Защита от изменения конфигов, как вариант. Иногда бывает работа с документацией и прочие глобальные изменения, когда явно надо запретить что-то изменять. Впрочем, как всегда можно всё это вынести в очередной репозиторий или обвешаться хуками.
    ---------------
    Впрочем, это не решение проблемы. Вспоминаю VSS - до сих пор вздрагиваю. А прошло уже лет так с 15-цать. Это когда кто-то забыл снять блокировку с файла. Зашибись решение, да, ничего не скажешь.

    И как вы предлагаете билдить? Выделяется ответственный разработчик, который собирает вручную билд и выкладывает его клиенту?
    ---------------
    Послушайте Торвальдса на google, там рассказывается, как организована работа kernel с git. А ведь в ядро коммитят реально огромное количество людей.

    Когда-то давно были придуманы бекапы. Очень полезная вещь, рекомендую!
    ---------------
    И я Вам рекомендую, прежде чем брать с собой ноут с кодом, делать бекап. Это давно придумано. Впрочем в svn все-равно коммиты делать не сможете.

    ОтветитьУдалить
  7. И плюсов что-то маловато у Вас для DVCS. Расскажите, как сделать и главное, легко сделать, в svn:
    1. Разбить один коммит на два;
    2. Обьединить два коммита в один;
    3. Сделать revert коммитов в середине дерева коммитов;
    4. Применить один и тот же коммит к нескольким бранчам (git cherry-pick);
    5. Сделать коммит по чанкам;
    6. Выдернуть нужные несколько коммитов из одного бранча и применить их к другому бранчу;
    7. Сохранять изменения (заначки) в файлах в структуре VCS сколько угодно раз, и применять по мере необходимости к любой ветке. Аналог git stash короче;
    8. Отредактировать последний коммит (git commit --amend);
    9. Аналог git bisect;
    10. Взять у товарища изменения, которые, к примеру, еще рано коммитить в origin и применить их в своей ветке;
    11. О какую рельсу надо стучаться, если центральное хранилище изменило свой адрес. Как в таких случаях коммитить свои изменения? Впрочем, применительно к svn, это риторический вопрос. Качать по-новой "100500 проектов в одном"?

    ОтветитьУдалить
  8. 12. Переименовать, перенести файлы без потери истории.

    ОтветитьУдалить
  9. 1. Задним числом? Что мешает сделать два коммита?
    2. Задним числом? Иначе не понимаю задачи
    3. Без проблем, реверт конкретной ревизии нормально делается.
    4. Как я понимаю задача состоит в том, чтобы смёржить определённую ревизию между двумя бранчами. Проблем в SVN не вижу. Берётся и мёржится.
    5. Красивого способа не знаю. Впрочем, как я и говорил в плюсах "более приличный мёрж"
    6. Без проблем, выдёргиваются и вмёрживаются. Причём достаточно часто.
    7. В SVN этого нет. Решается бранчами. Но при этом, это есть в TFS, к DVCS не имеет никакого отношения.
    8. Что ушло в систему контроля версий, то ушло. Сообщение при этом поменять без проблем
    9. svn-bisect
    10. Правильный путь работать в бранчах. Неправильный - патчи
    11. relocate и никаких проблем
    12. svn rename

    ОтветитьУдалить
  10. 1. Задним числом? Что мешает сделать два коммита?
    Задним числом. Есть разработчики, которые привыкли выполнять всю работу в один коммит, работая два месяца над какой-нибудь функциональностью и в последствии выкладывая 20к-строк в центральный репозиторий. Такие коммиты в заморских статьях называются "bombs", в рускоязычном слое называются - "нап*дорасил". Такие коммиты сложно проверить, ими сложно управлять(нельзя отменить часть изменений, который возможно что-то ломают). Имея свой локальный репозиторий - такой разработчик еще может что-то исправить.

    2. Задним числом? Иначе не понимаю задачи
    Задним числом. Необходимость в объединении коммитов возникает, к примеру, при рефакторинге. Очень часто - это большое количество небольших взаимоисключающих изменений.

    3. Без проблем, реверт конкретной ревизии нормально делается.
    Разработчик хочет отменить "решение" какой-то конкретной задачи, а не понизить ревизию у файлов.

    ОтветитьУдалить
  11. 1. Т.е. разработчик 2 месяца не пушил и даже не чекинил вообще, и ему нужна возможность локально вначале всё раскромсать потом уже запушить в удалённый? Какая-то странная задача, если честно, или я не понял задачу.

    2. А смысл? Чтобы красиво было? Т.е. неделю правим, выкладываем, потом посчитали что это неправильно и все ченджсеты слили в один?

    3. Это делается в SVN'е. Именно выпиливается конкретная задача.

    ОтветитьУдалить
  12. Все (или почти все) описанные недостатки решены в Perforce. У них получился эдакий симбиоз SVN и DVCS с поддержкой частичных мапов (не нужен весь репозиторий), возможность работы без сервера, поддержка большин бинарников, сквозная нумерация, блокирование файлов, разграничение прав на ветки и т.д.

    ОтветитьУдалить
  13. На мой взгляд, идеальная система --- это SVN и Git вместе на сервере одновременно. Так, чтобы коммит в SVN транслировался в Git, и наоборот. Как в GitHub'е, если бы в его SVN-поддержке не было столько багов.

    ОтветитьУдалить
  14. Имхо для единственного разработчика, достаточно DropBox.

    ОтветитьУдалить
  15. aperon, ты реально не в теме, прежде чем пользоваться svn'ом доки читал? похоже что нет. попробовал работать без доков, не разобрался и теперь гонишь.
    Не знать таких элементарных вещей как вот это это вообще пипец
    12. Переименовать, перенести файлы без потери истории.
    force дал тебе правильный ответ
    12. svn rename
    По остальным пунктам аналогично я уверен в твоей некомпетентности.
    И немного офтопа: что это за студент, который вспоминает как он 15 лет назад работал с svn'ом. 40-летний студент что ли?

    ОтветитьУдалить
  16. Коллеги, конкретный юз-кейс, который я, пока, не знаю как реализовать в git, а пользоваться его преимуществами хочется.
    1) Нужно проставлять ревизию и путь к файлу в репозитории при коммите. Т.е. хук в SVN.
    2) Имеется огромный файл схемы БД, который успешно мерджится, но после мерджа становится неоткрываемым. Можно ли на основе git или его костылей реализовать блокировку файла от множественных одновременных редактирований?

    ОтветитьУдалить
    Ответы
    1. 1. В гите хуки есть. Правда есть нюансы между локальным репозиторием и оридженом
      2. Нет. Мёрж происходит локально у каждого пользователя, т.е. можно запретить ему коммитить, но что он у себя натворил - это его дело. Зато можно в .gitattributes прописать как мёржить подобный файл (можно указать внешнюю тулзу, которая правильно всё сделает, или даст отлуп).

      Удалить