|
Персональные инструменты |
|||
|
Distributed Version Control Systems: A Not-So-Quick Guide ThroughМатериал из CustisWikiЭто снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений. Короткая ссылка: DVCS-A Not-So-Quick Guide Перевод статьи «Distributed Version Control Systems: A Not-So-Quick Guide Through» от Sebastien Auvray с портала InfoQ. Sébastien Auvray — senior software designer и энтузиаст технологий. Его заставляли использовать CVS и SVN, теперь он страдает на работе от ежедневного использования Perforce. Sébastien также один из редакторов InfoQ по теме Ruby.
После выступления Линуса Торвальдса в Google в мае 2007, просвященного GIT, постоянно растет интерес и число пользователей распределенных систем контроля версий (Distributed Version Control Systems, DVCS). Тут мы сначала сделаем краткое введение в понятия распределенного управления версиями, посмотрим, когда это стоит использовать, и почему, этом может быть лучше, чем то, что вы используете сейчас, и затем мы взглянем на трех ключевых игроков в этой области: git, Mercurial и Bazaar. Содержание[убрать]Так что же это?Системы управления версиями (СУВ, SCM, Source Control Management) следят за всеми версиями каждой информационной единицы. Обычно они используются в разработке ПО для ведения исходных кодов проекта. Самой древней из широко известных СУВ была CVS, разработка началась в 1986 году. С тех пор выросло множество СУВ, различным образом улучшающих CVS:
В декабре 1999, для ведения основного ствола исходников Ядра Линукса Линус выбрал BitKeeper, характеризовав его как «Лучший инструмент для этой работы». До этого, Линус вообще вручную интегрировал изменения из отдельных патчей. Все предшественники BitKeeper работали в централизованной модели «Клиент—(Центральный)Сервер», и BitKeeper был первой VCS разрешивший полную распределенность, когда каждый имеет собственный репозиторий. Но из-за лицензионных конфликтов, BitKeeper был отринут в пользу git (апрель 2005). Теперь есть и другие системы, использующие ту же модель: Зачем все это?Или даже более конкретно: «А чем не устраивают CVCS (Централизованные СУВ)? Subversion-то чем не угодил?» Вот в чем обвиняют Subversion:
Современные DVCS-системы все это исправили, как собственными фишками реализации, так и самой идеологией распределенности. Но, как мы увидим дальше, Subversion еще не сдается! Как?ДецентрализацияРаспределенные системы управления версиями выигрывают за счет «peer-to-peer»-подхода. Участники могут взаимодействовать друг с другом и поддерживать их локальные ветки без необходимости в центральном сервере и даже репозитории. То есть синхронизация идет между равными участниками, самостоятельно решившими, какими изменениями обменяться. Это приводит к сущетвенным отличиями и преимуществам над централизованными системами:
Даже если есть какой-нибудь центральный сервер (например, для релизов, бэкапов или стандартных версий), если правильно задействовать Распределенность, его не будут так же часто дергать, как в случае CVCS.
Для введения в непосредственно практики DVCS-разработки, можете взглянуть на статьи Intro to Distributed Version Control (Illustrated) или возможно Collaboration workflows. С другой стороны, стоит предупредить вас о некоторых проблемах выбора DVCS, особенно о проблеме сложности использования: этот децентрализованный подход весьма отличается от старого доброго Централизованного Мира, и может потребоваться время, чтобы ваши разработчики смогли им воспользоваться. Отслеживание наборов изменений (changeset) вместо ведения истории файлов тоже может запутать, несмотря на свою мощность, благодаря которой он сможет отслеживать такие вещи, как перемещение функции между файлами. Кто?А теперь контрольверсийсрач! «Что такое хорошо, и что такое плохо». Все эти плюсы и минусы собраны в основном из (вычитанной и проверенной, ибо многие аргументы устаревали) компиляции блогов и личного опыта. Учтите, что это весьма краткий лист свойств (например, у git более 150 команд), и что важность их разная. Для простоты, приведем сначала общие свойства всех трех систем:
Теперь приведем сводную таблицу различающихся свойств:
Полно еще споров, например, от том, что каталоги в Bzr это ветки, а не контейнеры веток, как в git.
Есть и другие нексколько предвзятые сравнения от Bazaar-команды: и соответственно, ответ на это: Обратите внимание, что в этом отчете не было возможности выбрать Ruby, неплохо было бы добавить его в опрос 2008 года[15]. Очень забавно, что треть людей используют DVCS взаимодействуюя с … 0 или 1 участниками![16]. GUIГрафический интерфейс ко всем системам хороший и примерно одинаковый, хотя gitk наверное эффективней. TortoiseHg (с активированной опцией «folder watch») сильно тормозит на больших репозиториях, типа Мозилловского. Краткий взгляд на производительность (не претендует на истину в последней инстанции)git по прежнему лидирует в битве за производительность, но Hg и Bzr существенно улучшились за последний год. Обратите внимание, что Mercurial удваивает количество файлов в вашем репозитории (история хранится по-файлово в Также интересно видеть, что у git большое преимущество за счет операционной системы при выполнении команд. Hg и Bzr не тратят большую часть времени в системных вызовах, а Git проводит в них до 10-40 % времени. Возникает ожидаемый вопрос, о том, будет ли его производительность также хороша под Windows, где git-разработчики не имеют доступа к ко всем возможностям системы, как у них было под Linux. Надо тестировать как отдельные слияния, так и слияние очередями, это связанная часть тестов. Бенчмарки надо также гонять под Windows, ибо:
См. #Условия тестов Когда?Истории использованияKelly O’HairМне удалось расспросить Kelly O’Hair из Sun на тему его выбора Hg для OpenJDK. Я прочел причины перехода с TeamWare на Mercurial, но остались вопросы. Вы просто последовали за выбором проекта OpenSolaris? Ну, в некоторой степени да, но выбор для OpenSolaris стал также очень распространенным выбором в Sun для всех команд разработчиков желающих куда-нибудь смигрировать. Исследование для OpenSolaris было впечатляюще исчерпывающим, и их требования в точности совпадали с нашим. Ну а так как нам надо было куда-то переезжать с OpenJDK, так как TeamWare для open-source проекта не подходит, выбор Mercurial стал для нас вполне очевидным. А вы пробовали освежить сравнение, и снова попробовать другие DVCS-системы (git, и т. п.)? Нет, мы не занимались перепроверкой, это наверно пустая трата времени. Единственной альтернативной на мой взгляд был git, но там не уделяли достаточно внимания работоспособности под Windows, а это нам было нужно. Так что повторюсь, выбор был очевиден. Так ведь отчету для OpenSolaris, который был опубликован в апреле 2006, уже два года стукнуло… Да знаю я. Что-то поменялось, git обновился, но Земля вертится, и Mercurial тоже улучшился. Какие особые проблемы встретились вам при миграции? Права и владения файлами могут быть проблемой при разделении репозитария через сетевые файловые системы, типа NFS или UFS, так что мы в конец концов настроили нормальный сервер для работы с разделяемыми репозитариями, так лучше. Это несложно. Еще мы столкнулись с проблемой, что использование триггеров (hooks) для отката или фильтрации push-изменений создает некоторое временное окно, в течении которого кто-то может вытащить (pull) изменения, которые должны быть откачены. В результате мы завели пару репозитариев — один для публикации изменений (push), другой — для извлечения (pull), и настроили между ними автоматическую синхронизацию, которая срабатывала после выполнения всех триггеров. Использование лесов (forests) также приводило к проблемам, так как forest-push по сути набор отдельных push-операций, и если одна из них падает, то по уму надо бы откатить и все остальные. Однако никто этого не делает, все надеются на удачу. Впрочем, если репозитории в лесе достаточно независимы, это не будет реальной проблемой. И как оно в повседневном использовании? Поживем — увидим. Такие изменения кому-то даются легко, кому-то — тяжело. Дайте время, я думаю большинство привыкнет и даже выучится это любить. Понятие «рабочих наборов файлов» (working set files, с чем работает hg update) и необходимость интеграции changeset-ов, которые непонятно с чем сливать, путает народ. Также идея пересылать changeset-ы а не отдельные файлы, для некоторых людей приводит к проблеме «Почему нельзя просто переслать вот этот вот один файл?». И чем это лучше, чем TeamWare? Много-много-много быстрее чем TeamWare. В перспективе наши команды в Китае и России перейдут на единую инфраструктуру сборки и интеграции, так как им не потребуется держать зеркала для серверов интеграции. Обновления (pulls) очень быстры даже при медленных соединениях. Состояние репозитория в Mercurial достаточно целостное, в отличие от TeamWare, который разрешал частичные workspac-ы, да и вообще TeamWare всего лишь дырявая авоська с индивидуально учитываемыми (SCCS-) файлами. Понятие набора изменений (changeset) в TeamWare отсутствует, вместе с понятием определенного состояния репозитария целиком (то есть просто id-а, changeset-а). Так есть что-то, что вам не хватает от TeamWare? Ребятам не хватает оповещений через email, и еще истории транзакций «putback/bringover», хотя многое из этого можно вытащить из changeset. Возможно еще не хватает чего-то типа истории транзакций с репозиторием, но опять таки, почтовых архивов событий от Mercurial было бы достаточно. Так Hg стал избранной Sun-ом СУВ для всего, включая внутренние проекты? Или Sun использоует ее только для публичных проектов, которым требуется открытость? Да мы все проекты переносим, как внутренние, так и внешние, там где это имеет смысл разумеется. Вижу, что растет интерес решившихся на это проектов. Pierre d’HerbemontТакже мне удалось расспросить на тему git и Pierre d’Herbemont из VLC. Для начала, какую систему управления версиями вы использовали до git? SVN, затем зеркало git-svn. Мы открыли git-зеркало для svn-репозитория, чтобы облегчить участие VLC в Google Summer of Code. Это что предшествало этому. Затем мы полностью мигрировали на git 1-2го марта 2008. А почему вы выбрали Git, а не его конкурентов? По пунктам:
Были у вас какие-нибудь специфические проблемы с миграцией? А с ежедневным использованием? Были проблемы с Trac и buildbot. У них поддержка Git была минимальной, особенно в их релизных версиях. Нам пришлось вытаскивать последние версии Builbot из исходников. Для Trac мы использовали убогий Git-плагин, который требовал Trac 0.11. Но Trac 0.11 еще не стабилен, там есть несколько известных утечек памяти, которые удерживают нас от переключения. В общем, мы ждем, когда они это починят… Некоторым контрибьюторам требуется некоторое время, чтобы освоится с Git. Но через пару дней, все оказывается в порядке. И многие git-ньюбы начинают действительно им наслаждаться. Ну и что?Выбор между распределенными и централизованными СУВ далек от простоты. DVCS определенно изменят практику вашей работы, как индивидуальной, так и командной. Subversion, один из лидеров CVCS не сдается[18] и в производительности, и по функционалу и версия 1.5 уже должна быть неплохим компромиссом. Он может рассчитывать на существущих пользователей и дух простоты (за счет некоторых неудобств). В определенных случаях, как например в работе с большими бинарными файлами, Subversion должен быть лучше, чем DVCS так как пространство под рабочии копии остается неизменным. Также он эффективней, если вы активно используете частичные checkout-ы, (хотя если это происходит часто — это явная проблема недостаточного разбиения вашего проекта на модули). Даже если вы сделаете свой выбор в пользу DVCS или CVCS, то будет сложно сравнить конкурентов в выбранной области, то есть реализация (например, команды) и соответственно их производительность, будет существенно отличаться. Нет ни одного теста производительности даже для общих операций. В этой жесткой битве, Bazaar потерял многих, очень важных и влиятельных ранних пользователей-энтузиастов (Mozilla, Solaris, OpenJDK) из-за плохой начальной производительности. Еще стоит заметить, что вебсайт Bazaar был слишком «маркетинговым»: публиковались не совсем честные сравнения с конкурентами, или тесты производительности по отдельным параметрам, в которых система превосходила конкурентов (см. например Space efficiency), при том, что не было сравнений по времени для ежедневных команд: diff, add, … Мне кажется, что хотя все эти три проекта стартовали примерно в одно и то же время, bzr с самого начала столкнулся с множеством проблем в производительности и архитектуре, что привело к тому, что он сейчас чуть менее зрел и надежен, чем его конкуренты. И еще ранее не наблюдавшийся феномен — похоже, что многие делают выбор в зависимости от языка программирования сообщества:
Надеюсь, эта статья вас просветила, и я всегда рад узнать о вашем опыте и иным отзывам! БлагодарностиБлагодарю тех, кто любезно согласился на мое интервью: Kelly O’Hair, Pierre d’Herbemont. Ian Clatworthy за его оперативную помощь в преобразовании hg-репозитория Mozilla в Bzr. IRC-каналы #git, #mercurial, #bzr на Freenode IRC, #mozilla на Mozilla IRC. Картинка с бегунами от Antonio Juez. Случайные цитаты
Статья была обновлена 2008-05-12 после коммантариев от Ian Clatworthy и портала reedit.
Извиненияdarcs, Monotone! Простите, что не рассматривал вас в этом сравнении, так как мне и так пришлось неслабо поработать чтобы собрать всю эту информацию и протестировать эти три DVCS. Да, странно получилось, что хотя вы самые старые на DVCS-сцене, актуальны теперь в основном те DVCS, которых я рассматривал тут (конечно, вряд ли эта ситуация измениться, но добро пожаловать пользователям darcs и Monotone с комментариями и рекламой!). Ссылки
Distributed Revision Control Wikipedia page. Comparison of Revision Control Software Wikipedia page.
Ну и все URLы, так или иначе упомянутые в этой статье. ШпаргалкиУсловия тестовBenchmark conditions Тесты были проведены с использованием:
Каждую команду запускали 8 раз, с отбрасыванием лучшего и худшего времени. Все это выполнялось локально, через файловую систему (надо конечно протестировать и остальные протоколы, ведь даже если DVCS не связана с центральным сервером, плохо реализованное сетевое взаимодействие существенно ухуджит и производительность пользователей. Использовались следующие версии:
Репозиторий содержал слепок из 12456 changeset-ов (от 20080303, 70853 полных версий из hg-репозитория), ≈30000 файлов из репозитория Mozilla (изначально они были в hg-формате и сконвертированы в git-репозиторий с помощью hg-fast-export.sh, и
в Bazaar-репозиторий с помощью hg-fast-export.sh плюс плагин fast-import).
Для репозиториев использовались файловые форматы по умолчанию, и размер репозитория git оставался постоянными, при запуске git-gc (что в общем, считается нормальным для свежемигрировавшего репозитория). Правился один файл ( Примечания
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||