Онлайн консультант Онлайн консультант
Контакты
Город: Барнаул
  • Москва
  • Санкт-Петербург
  • Барнаул
  • Алматы
Бизнес_с_нами
Бизнес с нами
Оставить_заявку
Оставить заявку
EVENTS

Немного про системы контроля версий(SVN, Git, Mercurial, Bazaar). Выбор.

11 октября 2008

С недавнего времени, а именно месяца полтора назад, начал впервые использовать систему контроля версий (Subversion,SVN). Понятны стали все преимущества использования VCS(Version Control Systems, система контроля версий) в разработке, даже если разработчик один, а уж если команда трудится над проектом, то тем более.

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

Недели две назад решил “взять быка за рога” и применить какую-нибудь VCS в нашем рабочем процессе в Митре. Особенно это стало актуально в последнее время, когда почти все разработчики работают удаленно и стало сложно синхронизировать свои действия. К тому же хотелось контроль за изменениями в проектах повесить на какую-нибудь автоматическую систему.

Первым, что пришло на ум, это было, конечно, использовать SVN. По этой системе очень много документации, написано множество удобных клиентов для разных платформ, сервер идет в комплекте с практически каждым дистрибутивом Linux, установка и настройка сервера не составляет труда. К тому же есть прекрасные плагины для Eclipse для работы с SVN, Subclipse и Subversive.

Но есть у SVN и недостатки, которые немного снижают эффективность ее применения.

Первое, это сам принцип работы svn: так как snv централизованная система, то требуется наличие сервера и соединение с ним для отправки коммитов, что снижает возможности делать частые коммиты. Для индивидуальной разработки сервер не обязателен, но для командной без него никак. Таким образом нужен постоянный доступ в инет и постоянно работающий svn-сервер для синхронизации. Конечно, это не особо большая проблема, но несколько напрягает.

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

Третье - опять же ориентируясь на мнение умных людей, решили присмотреться к перспективным разработкам распределенных систем контроля версий(Git,Mercurail,Bazaar), призванных избавить от недостатков svn.

Добил просмотр выступления Линуса Торвальдса, в котором он критикует svn, рассказывает о преимуществах DVCS(Distributed Version Control Systems, распределенная система контроля версий).

Приведу некоторые соображения и выводы, которые сделал, поизучав каждую из обозначенных DVCS.

Git

Начал изучение с системы Git, потому как разработка самого Линуса, и зарекомендовала себя как очень гибкая и скоростная система.

“Git выделяется главным образом из-за того, что он применяется для разработки ядра Linux. Собственно, именно для этого Git и разрабатывался. Ядро Linux - весьма немаленький проект, как по объему исходного кода, так и по числу участников, поэтому при его разработке большое внимание было уделено производительности и легкости слияния веток.” - iportnov.ru

Почитав документацию первым делом нашел плагин для Eclipse, JGit/EGit, потому как работать в консоли привык еще не настолько, чтоб работать только в ней, к тому же моих соработников врядли устроит такая перспектива. Любое изменение и улучшение процесса работы должно быть легким и не нозящим, иначе пользоваться никто не будет.

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

git позволяет обращаться к хранилищу по http, https, ftp, sftp, file(если репозиторий локальный), ну и по внутренним протоколам git и git+ssh.

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

Первое - это слабая поддержка работы в среде Windows. Нет, можно конечно запустить через эмулятор, но на мой взгляд это не дело.

Второе - отсутствие полноценных графических клиентов для git. Git как “настоящая unix-программа” заточен для работы именно из командной строки. Даже плагин JGit для Eclipse позволяет выполнять лишь базовые операции по работе с git-репозиториями, такое допустимо лишь для индивидуальной разработки. Сложно ожидать другого от разработки самого Линуса )) Может в будущем и появятся достойные внимания графические клиенты и для Windows и для Linux, но пока я таких не нашел.

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

Bazaar

Как то исключил из рассмотрения сразу, начитавшись многочисленных отзывов о гораздо более низкой скорости работы системы, по сравнению с конкурентами git и mercurial, и неустойчивой и противоречивой от версии к версии системе api(что заставит часто обновлять ПО сервера). Единственно что привлекло, так это заявленная работа в Windows. На счет скорости, говорят что ситуация улучшается от релиза к релизу, посмотрим. Возможно сделаю обзор по применению и этой системы, все таки надо быть в курсе о возможностях аналогов.

Mercurial

Практически полный аналог git, они даже считай одного возраста ). Все возможности, скорость работы сопадают у этих систем, есть только незначительные различия. Удобство использования выше чем у конкурента. Считается, что разработчики mercurial-a перенимают фичи у git, а разработчики git подсматривают у mercurial-a приемы повышения удобства использования. Поэтому не буду описывать много и сразу напишу чем он меня “подкупил”, почему мы выбрали именно его.

Первое, что меня поразило в mercurial, это плагин к Eclipse. Это вам не хиленький набор из базовых функций, а полноценный графический клиент. Позволяет выполнять практически все операции по работе с репозиториями, создавать проекты прям в процессе клонирования(а не через промежуточный шаг как в git), каждый пункт в меню украшен иконкой(мелочь, а приятно). Вобщем удобно очень, почти как c svn )

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

Третье - наличие системы плагинов, которые расширяют и без того нехилые базовые возможности dvcs. Хочу опробовать в ближайшее время плагин Forest, который позволяет объединять отдельные репозитории в один большой, вернее эмулирует работу с объединенным репозиторием.

Итого: будем пробовать на работе внедрить систему контроля версий Mercurial, именно эта система показала себя гибкой и удобной в использовании, по сравнению с другими. Несмотря не это, буду продолжать следить за разработкой Git и Bazaar.

Ссылки по теме:

Про Git

Официальный сайт системы Git

Системы контроля версий. Git.

Руководство пользователя GIT (для версии 1.5.3 и выше)(русский перевод)

Девять причин перейти на Git

Несколько слов про git.

Про Mercurial

Официальный сайт Mercurial

Mercurial: введение в распределённые системы контроля версий

Готовое решение: обновляем свой сайт через систему контроля версий файлов mercurial.

Про Bazaar

Официальный сайт Bazaar

Примеры взаимодействия разработчиков с помощью dvcs, интересно без относительно к конкретной системе


Понравилось? Давайте расскажем об этом миру!