вторник, 5 апреля 2011 г.

Понять ветвления

Централизованные системы контроля приучили нас к единому репозиторию. Ветвления осуществляются между каталогами, или депотами, как их не назови. Ну CVS мы за систему контроля (поддерживающую ветвления) вообще не считаем. Во всех остальных, насколько я знаю - деревья.

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

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

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

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

Есть возможности публиковать только часть изменений - git публикует текущую ветку, mercurial'у можно указать что публиковать (со всеми парентами). При этом mercurial выталкивает на сервер все родительские коммиты. Сделал локальное слияние - все уйдет на сервер.

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

Думал, что можно выбрать в качестве альтернативы для текущей, централизованной системы? Mercurial вероятно наиболее подходящий кандидат. Во первых в базе Меркуриала есть номера ревизий. Пускай в каждой клонированной базе и свои, главное, что на сервере они неизменны. Я могу применять их в сборках и при этом сборки однозначно будут идентифицироваться с соответствующим коммитом. Этим свойством обладают почти все централизованные, и отсутствие этого служит препятствием к переходу. git или bazar не обладают такой упорядоченностью и компактностью (одна цифра) версий.

В остальном системы, по моему, идентичны. В bazar вообще нет локальных ветвлений, но как написано выше, они и в mercurial не особо помогают.

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

10 коммент.:

Aquary комментирует...

> Ну CVS мы за систему контроля (поддерживающую ветвления) вообще не считаем

Зачем так обижать ветерана? :) Ветки он поддерживает отлично и версии там представляются в виже дерева для каждого элемента. И в этом смысле SVN был шагом назад с его веткой в виде копией дерева каталогов (ИМХО).

> Mercurial будет грязно ругаться, если ты не предполагаешь публиковать его на сервере.

Локальные бранчи есть, см. книжку Mercurial the Defenitive Guide. Причем под бранчами автор подразумевает как простой клон репо, так и ветку в более традиционном понимании (как ветвление версий в том же репо).

> Думал, что можно выбрать в качестве альтернативы для текущей, централизованной системы?

А надо ли? :) Работает - не трогай ;)

Unknown комментирует...

snv log --stop-on-copy

это чтобы посмотреть инсторию с момента бранча.

svn log (без --stop-on-copy) - посмотреть всю историю (уйдет в транк если оттуда пришли исходники).

Ну а дальше можно диффать ревизии до посинения, если ветка создавалась с помощью svn copy - вся история будет на месте.

svn конечно не идеален, но ветки и истории по ним там значительно лучше сделаны чем в cvs

Andrey Valyaev комментирует...

Aquary: Если ты в меркуриале делаешь ветвления и слияния локально - то тебе придется вытолкнуть свои ветки в апстрим. У тебя нету выбора.

Он говорит - что ты создал новую ветку, если ты хочешь загнать ветку в апстрим - ты должен сказать -f. или можешь стереть свою базу нафиг.

На CVS я довольно долго сидел... он конечно ветеран, я его уважаю :). Но по современным понятиям он совершенно не катит. Целостности в нем нету.

Дмитрий: Историю не с момента ветвления, а историю изменений в ветке, которую формируют путем слияний. Вот к примеру FreeBSD 8 (stable):


r220310 | hselasky | 2011-04-04 02:21:40 +0400 (Пнд, 04 Апр 2011) | 5 lines
MFC r219848.

r220309 | hselasky | 2011-04-04 02:15:00 +0400 (Пнд, 04 Апр 2011) | 6 lines
MFC r219845, r219930, r219949 and r219983.

r220308 | hselasky | 2011-04-04 02:01:26 +0400 (Пнд, 04 Апр 2011) | 12 lines
MFC r219048, r219004, r218475 and r204632.

r220307 | hselasky | 2011-04-04 01:12:16 +0400 (Пнд, 04 Апр 2011) | 5 lines
MFC r217374

и тд...
Да, там конечно есть еще что-то. Люди подходят к делу ответственно и в мессадже собирают информацию о вливаемых изменениях.

Но деталей нету - их надо искать в транке.

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

А тот же Меркуриал - все коммиты переносит. детали будут доступны в любой ветке.

Aquary комментирует...

> Если ты в меркуриале делаешь ветвления и слияния локально - то тебе придется вытолкнуть свои ветки в апстрим. У тебя нету выбора.

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

Но, конечно, это не совсем выход.

Andrey Valyaev комментирует...

Aquary: Это и явилось для меня в некотором роде прозрением. :)

С базаром все понятно, у него вообще локальных бранчей нету. А вот в других то есть. :)

Нужно разделять ветки. Можно и в одной базе ветвить, только именованные бранчи отметаются и надо применять политику вытягивания. Из default тянешь в branch а не наоборот до тех пор, пока не будешь готов залить свои изменения. и не в коем случае не делай неконкретный push все уйдет в апстрим :)

Сложностей много - короче клонировать!

Andrey Valyaev комментирует...

С таким же успехом можно работать в дефолте и делать update/rebase до тех пор, пока не будешь готов сделать push...

И для корпоративной разработки - это минус... работа без коммитов получается. Нужно ограничивать объем функциональности.

Смысл в том, что локальные бранчи получается - не нужны.

Aquary комментирует...

Вот за это и недолюбливаю DVCS. Провоцирует к хаосу и расползанию дельты. Чтобы это работало эффективно и безошибочно в большой команде, нужны немалые организационные меры.

Анонимный комментирует...

> git или bazar не обладают такой упорядоченностью и компактностью (одна цифра) версий.

Я думаю, что вам и не нужны номера ревизий как таковые, а нужна возможность удобно и понятно сослаться на ревизию. Для этого в git есть команда describe, которая выдаст однозначное (но удобное и понятное человеку) описание коммита.

Например, git describe может выдать нечто вроде "0.1.1-87-ga3108fb" - это означает, что после версии 0.1.1 (git describe берет ближайший тег) прошло 87 коммитов (вот он, номер ревизии) и что хэш коммита начинается на "a3108fb". Для версии 0.1.1 describe выдаст просто "0.1.1".

Andrey Valyaev комментирует...

dmitry-vk: Это возможность прикольная... но возможно ли будет потом найти ревизию 0.1.1-87 (Наша версия продукта состоит из 4 цифер), Если тестировани например сфейлится?

Вообще у git очень много всяких команд - это минус. :)

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

Andrey Valyaev комментирует...

То есть получается что в describe самое ценное - это опять таки хеш ревизии, который еще никого не обманул. Или тег :)

а циферка 87 - очень абстрактная.