Выбор DVCS (распределённой системы контроля версий) (у кого какой опыт?)

[t.t]

Стою сейчас перед выбором DVCS для внутренних проектов компании. Раньше работал только с CVCS (CVS, Subversion и -- страшно вспомнить -- SourceSafe). Уже много чего нашёл почитать в сети, но интересно было бы узнать и о личном опыте -- особенно об опыте такого же выбора.

Пока больше склоняюсь в сторону Mercurial, но интересна информация и по другим DVCS. Если вкратце, то всерьёз пока рассматривал только трёх претендентов: Git, Mercurial и Bazaar (о других вообще мало что знаю). Базар отпал из-за скорости -- в моём случае это критично. Из оставшихся двух в пользу второго говорит, к примеру, вот эта статья: http://code.google.com/p/support/wiki/DVCSAnalysis
Хотя не знаю, насколько она не предвзята.

Следующая задача в планах -- прикручивание багтрекера, потому если такой опыт есть, тоже весьма приветствуется. Как по отдельным распределённым же багтрекерам (посматриваю в сторону Bugs Everywhere) в сочетании с DVCS, так и по Fossil, у которой есть свой -- информации в сети по Fossil почему-то достаточно мало; в частности, сравнительной с другими вариантами вообще не нашёл.

[Portnov]

Первым делом замечу, что тема потенциально флеймогонная ;)

Я использую git, доволен. Кроме всего прочего - с его развитием всё ясно "на века", благодаря использованию проектом linux kernel. git bisect, git commit --interactive, git rebase -i, git mergetool - это, по-моему, гениальные инструменты.

Базар кстати, говорят, в последних версиях стал приемлем по скорости.

[t.t]

Первым делом замечу, что тема потенциально флеймогонная

Я расчитывал на то, что она достаточно серьёзная -- т.е. те, кому будет что аргументировано сказать по теме, вряд ли будут отвлекаться на "мерялки".

Я использую git, доволен. Кроме всего прочего - с его развитием всё ясно "на века", благодаря использованию проектом linux kernel. git bisect, git commit --interactive, git rebase -i, git mergetool - это, по-моему, гениальные инструменты.

А критерии для выбора какие-то были, кроме "использования проектом linux kernel" (который, на мой взгляд, достаточно субъективен)? Или другие варианты не рассматривал?

[Portnov]

Я просматривал документацию по разным dvcs, спрашивал на форумах. Судя по всему, dvcs отличаются только второстепенными вещами. На сколько-то процентов различается скорость, немножко разное использование веток... Так что на первый план выходят личные предпочтения и прочие посторонние соображения.

[t.t]

Я просматривал документацию по разным dvcs, спрашивал на форумах.

Этим сейчас и занимаюсь. (:

Про BE тоже немного почитал наперёд. Похоже, её использовать что с git, что с Mercurial будет вполне удобдно.

Судя по всему, dvcs отличаются только второстепенными вещами. На сколько-то процентов различается скорость, немножко разное использование веток... Так что на первый план выходят личные предпочтения и прочие посторонние соображения.

Да, уже похоже. С одной поправкой: личные предпочтения -- это для личного же использоваиня; для "рабочего" же -- специфика работы.

В частности, по последнему пункту возник вопрос по git. О нём много где писали, что под виндой всё плохо, но писали не позже конца прошлого года, насколько я нашёл. Насколько эта проблема сейчас актуальна? Для меня это критично: у нас часть разработчиков только с виндой.

[Portnov]

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

Upd. Пока использую локально, но не вижу предпосылок к проблемам работы по сети.

[t.t]

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

Тем не менее, если кому-то ещё будет что сказать по DVCS, буду благодарен.

[sciko]

А что сказать? Сейчас эти три столпа DVCS сравнялись. Остались только детали.
Ну и идеология чуть разниться: например, git всегда выделялся большим количеством команд, bzr -- возможностью использования множества подходов, а hg -- упором на скорость и простоту.
Короче, остались только личные предпочтения и внешние факторы (типа доступности хостинга). Поэтому мой совет: посмотрите близкое по функционалу ПО и чем они пользуются.

[IMB]

Уважаемые, сейчас у себя тоже планируем внедрить систему контроля версий. На данный момент наиболее привлекательно выглядит Subversion потому как:
- широко интегрирована во многие продукты, в том числе и коммерческие
- имеет стабильные клиенты под Windows, большинство разработчиков у нас работает в ней
- присутсвует система распределений прав доступа на сервере, для коммерческой организации это достаточно важный фактор
- есть возможность развернуть сервер на Windows
Прочитав по Git и Mercurial я не смог ответить на достаточно важный вопрос - как в них разграничить доступ к репозиториям на сервере?
Для Git я нашёл только gitosis, но он, насколько я понял, разграничение прав делает на основе SSH-ключей, что достаточно не удобно. Для Mercurail вроде есть некое AclExtension, но как его применить на несколько репозиториев сходу не понял.
Собственно вопрос прост - насколько в DVCS, в данном случае Git и Mercurial, возможно настроить разграничение прав доступа?
Спасибо.

[Portnov]

gitosis рулит, очень удобная вещь.

на основе SSH-ключей, что достаточно не удобно.

!? Наоборот, удобнее сложно придумать.

Вообще, модель dvcs предполагает, что права доступа не нужны. Ибо у каждого - свой репозиторий, и он очевидным образом имеет на него все права. Такие вещи, как gitosis, нужны только если использовать dvcs в централизованном режиме, а это не всегда лучший выбор. Даже если действительно нужен главный репозиторий - достаточно, чтобы он был на машине главного разработчика, и, соответственно, только он будет иметь права делать туда push; все остальные подают ему заявки, по которым он может делать pull.

Эту схему подробно разбирает Линус: http://www.youtube.com/watch?v=BtAlN4MaBr8...&playnext=1 (видеоперевод его выступления в google tech talks).

[IMB]

Тут видите ли в чём закавыка - нет главного разработчика. Есть руководитель проекта и есть разработчики и программисты. Не думаю, что руководитель проекта будет в восторге от необходимости делать обновления центрального репозитория, передав эту работу одному из разработчиков также не очень удачная мысль в силу того, что ему хватает и своей работы и он просто может не разбираться в данной области. Для примера, я выступаю, если более честно, то начинаю, Linux-программистом, на мне модификация/написание kernel-space и user-space, если кратко выражаться, мой коллега программирует микроконтроллеры, DSP и тому подобное, другой коллега разводит платы. Проект один, но состоит он из многих компонентов и ни один из нас не способен полность заменить/проконтролировать другого. Централизованный сервер удобен тем, что я могу получить доступ ко всем материалам которые мне нужны для работы.
Для примера - недавно в основном завершили работу по MSP430. Я написал драйвер для общения с ним по I2C и программу для теста, коллеги написали такую же часть со стороны микроконтроллера и развели всё это на плате. В процессе отладки всего не раз требовалось "дёргать" друг друга по разым вопросам. При наличии центрального сервера я мог бы сам скачать схему разводки и просмотреть код выполняемый на стороне микроконтроллера.
Сосбственно говоря почему я заговорил о DVCS хотя из моих слов выходит, что нам скорее подходит централизованная система. В силу того, что сроки могут быть достаточно сжатые подчас работу приходится продолжать вне стен офиса. Открывать нам доступ извне не выглядит привлекательно по ряду причин, да и в отсутсвии доступа в интернет это ничего бы не изменило бы. DVCS тут могло бы помочь.

[Portnov]

он просто может не разбираться в данной области.

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

При наличии центрального сервера я мог бы сам скачать схему разводки и просмотреть код выполняемый на стороне микроконтроллера.

А что вам мешает сделать это при отсутствии центрального сервера? Just

Код: Выделить всё

$ git remote add john ssh://john.provider.com
$ git fetch john
$ git checkout -b johns_code john/master

или что-то в этом духе. Протоколов git поддерживает кучу, не обязательно именно ssh.

Ну и gitosis никто не отменял.

[IMB]

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

[kamre]

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

Так пусть новый сотрудник и коммитит в свой локальный репозиторий, а затем просит своего наставника сделать pull и провести code review. Если все будет хорошо, то наставник сделает push в "центральный" репозиторий. Проблема не ясна.

[Portnov]

Вот хорошая ссылка про gitosis: http://habrahabr.ru/blogs/ror/64209/ .

[deadhead]

t.t, IMB на чем остановили свой выбор?
Есть как Windows, так и Linux разработчики. Стиль работы - что-то приходится доделывать вне офиса. Предполагается иметь "центральный" репозиторий. Нужен еще багтрекер. Что можете сказать про распределенные системы вроде BE? Можно ли будет локальные багрепорты объединять для "центрального" репозитория?

[IMB]

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

[t.t]

t.t, IMB на чем остановили свой выбор?

Пока всё не настроил по внутренним причинам фирмы. Но выбор уже сделан: 98%, что это будет Mercurial. Причины просты: по скорости и возможностям почти не уступает git, но существенно проще как в администрировании, так и во "вхождении". Среди действующих разработчиков с DVCS ранее имел дело только один (и это был Mercurial), а один не имел дела с VCS вообще, как и с линуксом. Кроме того, в ближайшее время планируется брать новых людей, и опыт работы с VCS тоже не будет ключевым пунктом их резюме. Так что последний пункт оказался решающим.

Отслеживание ошибок тоже планирею прикручивать. Пока рассмотрел не все варианты, но не исключаю, что это будет be.

[deadhead]

Тоже склоняюсь в сторону Mercurial, главным образом, по причине его кроссплатформенности. Из наспех выявленных недостатков - проблемы с кодировками (cp1251, 866) под оффтопиком (подробности здесь и здесь).

Отслеживание ошибок тоже планирею прикручивать. Пока рассмотрел не все варианты, но не исключаю, что это будет be.

Держите в курсе событий ;-)

[Portnov]

Хм. По поводу кириллицы - я как-то за время работы со свободными проектами настолько привык к тому, что в исходниках и в commit message-ах не может быть ничего кроме английского языка, что мне такая проблема даже в голову не пришла :)

[deadhead]

Хм. По поводу кириллицы - я как-то за время работы со свободными проектами настолько привык к тому, что в исходниках и в commit message-ах не может быть ничего кроме английского языка, что мне такая проблема даже в голову не пришла

Приходится еще и некоторый документооборот вести... да, и проблема лишь в именовани файлов: кириллица... решение есть, но еще не опробовал :-)

[ucalculus]

Ответ в 2 предложения: у git больше возможностей, но и больше команд, он сложнее(???).
У меркуриала все чуток проще. Гит == перл, меркуриал == питон.

[deadhead]

Ответ в 2 предложения: у git больше возможностей, но и больше команд, он сложнее(???).
У меркуриала все чуток проще. Гит == перл, меркуриал == питон.

Вопрос бы хоть прочитали

Выбор DVCS (распределённой системы контроля версий), у кого какой опыт?