article

1 2 3

DVCS Теги vs ...

	От:	WolfHound rsdn
	Дата:	18.03.10 12:13

Размышляя на тему DVCS я задумаля, а нужны ли бранчи как отдельная абстракция?
Ведь для организации всего что связано с бранчами достаточно тегов.

Тег в данном случае имеет имя и опционально некоторые ассациированные данные.
На одну ревизию можно повесить несколько тегов с одним именем.
Например тег comment содержит комментарий к ревизии.
Если comment будет содержать не только текст но и ссылку на предыдущий comment то можно бедт отвечать на чужие comment'ы.
Если теги сделать версионными то можно будет редактировать comment'ы.
Таким образом можно обсуждать ревизии.

Тег ticket может модержать ссылку на трекер.

Теперь рассмотрим работу с таким версионником(я буду расписывать достаточно подробно но не стоит забывать что рутинные действия лего автоматизируются):

Начнем с простейшего варианта: Все сидят в транке.
Коммит происходит следующим образом:
Делаем коммит.
Далее говорим смержить все ревизии на которых есть тег trunk. Тк версионник отслеживает что уже было смержено то мержить придется только новые изменения.
Если нечего мержить то просто вешаем тег trunk на нашу ревизию.
Если нужен мерж то мержим и вешаем тег trunk на ту ревизию что получилась. Также на эту ревизию можно повесить тег merge-only чтобы при просмотре логов она глаза не мозолила.

Преимущества перед svn:
Нет риска потерять изменения при мерже.
Разработчик автоматически попадает в персональный бранч просто не вешая тег trunk.

Теперь если нам понадобился бранчь для нескольких разработчиков то мы немного меняем процсс описаный выше.
Вместо тега trunk вешаем тег branch-XXX. И мержим ревизии у которых есть тег trunk и/или branch-XXX.
Когда нам нужно отправить изменения в trunk то мы кроме тега branch-XXX вешаем еще и тег trunk.

Дальше больше.
Если мы не хотим иметь в trunk'е то что не компилируется то мы вместо тега turnk вешаем тег trunk-candidate.
Теперь билд сервер видя ревизию с меткой trunk-candidate и без метки build-report собирает данную ревизию и вешает на нее тег build-report с отчетом о сборке.
Если собрка прошла успешно то вешаем тег trunk.
Не достаточно только сборки? Нивапрос. Запускаем тесты и вешаем тег test-report с отчетом о том как прошли тесты.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>

Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн

Re: DVCS Теги vs ...

	От:	Mr.Cat
	Дата:	18.03.10 13:02

Здравствуйте, WolfHound, Вы писали:
Похоже на branching with bookmarks (http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/).
Если не совсем то — думаю, реализуемо в виде плагина к mercurial.

Re: DVCS Теги vs ...

	От:	Aquary	http://scm-notes.blogspot.com/
	Дата:	18.03.10 13:16

WH>Размышляя на тему DVCS я задумаля, а нужны ли бранчи как отдельная абстракция?

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

WH>Ведь для организации всего что связано с бранчами достаточно тегов.
...
WH>Тег в данном случае имеет имя и опционально некоторые ассациированные данные.
WH>На одну ревизию можно повесить несколько тегов с одним именем.
...
WH>Делаем коммит.

Для более полного ответа воспользуюсь своими же статьями по основам SCM, опубликованными в RSDN Magazine: часть 1, часть 2.

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

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

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

В твоих сценариях метка именно это и делает — обозначает конфигурации, но не делает другой не менее нужной вещи — она не выделяет последовательности версий. Надо ли здесь приводить примеры, когда возникает необходимость ответвления разработки от основного направления?

WH>Короче с тегами которые могут содержать произвольные данные можно творить много интересных вещей.

У тебя есть большая отбивная. Есть вилка и нож. Вилкой можно творить много интересных вещей — салатик кушать, например, или оливки накалывать.
Можно взять её, наколоть отбивную и откусывать по кусочку.
А можно взять просто нож и есть только ножом — есть в этом свой кайф.

Однако же отбивную лучше резать мелкими кусками — и делать это ножом и вилкой! Ножом режем, вилкой накалываем и едим. Кстати, есть ещё и ложка — мы на флоте только ими и ели.
В общем, что в этой аллегории ветки, метки и прочие сущности — подбери сам, однако суть не меняется: не надо заниматься ерундой, придумывая на пустом месте то, что уже давно придумано.

https://wmspanel.com/ — Wowza and Windows Media control panel.
http://scm-notes.blogspot.com/ — Блог об управлении конфигурацией, контроле версий, управлении изменениями и вообще SCM

Re[2]: DVCS Теги vs ...

	От:	WolfHound rsdn
	Дата:	18.03.10 13:50

Здравствуйте, Aquary, Вы писали:

A>В твоих сценариях метка именно это и делает — обозначает конфигурации, но не делает другой не менее нужной вещи — она не выделяет последовательности версий. Надо ли здесь приводить примеры, когда возникает необходимость ответвления разработки от основного направления?
Ты видимо что-то не понял.
Тег с одним именем можно повесить на множество ревизий.
Далее тупо выбираем все ревизии с этим тегом. Вот тебе твоя последовательность.
Если были ветвления тоже не проблема.
Весрионник сохраняет всю историю о том что от чего произошло и с чем было смержено.
Таким образом мы можем легко отобразить не только все версии конфигурации но и то какая версия от какой произошла скрыв все промежуточные ревизии.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>

Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн

Re[3]: DVCS Теги vs ...

	От:	Aquary	http://scm-notes.blogspot.com/
	Дата:	18.03.10 22:20

Здравствуйте, WolfHound, Вы писали:

WH>Тег с одним именем можно повесить на множество ревизий.
WH>Далее тупо выбираем все ревизии с этим тегом. Вот тебе твоя последовательность.
WH>Если были ветвления тоже не проблема.
WH>Весрионник сохраняет всю историю о том что от чего произошло и с чем было смержено.

Тогда уточни, я правильно ли понял — ты предлагаешь версии складывать на одной ветке (АКА trunk), одну за одной, и при этом всю информацию — какая версия от какой отрощена — сохранять в тегах?

Re[4]: DVCS Теги vs ...

	От:	Roman Odaisky
	Дата:	18.03.10 22:30
	Оценка:	+1

Здравствуйте, Aquary, Вы писали:

A>Тогда уточни, я правильно ли понял — ты предлагаешь версии складывать на одной ветке (АКА trunk), одну за одной, и при этом всю информацию — какая версия от какой отрощена — сохранять в тегах?

А веток-то на самом деле и не существует. Есть только набор ревизий и связи между ними. Поэтому переходящий с ревизии на ревизию тег trunk ничем не отличается от ветки trunk. Информация же о предках и потомках ревизий хранится в них самих, как сейчас это и происходит в РСКВ.

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

status=sent (delivered to file: /dev/null)

Re: DVCS Теги vs ...

	От:	Roman Odaisky
	Дата:	18.03.10 22:34

Здравствуйте, WolfHound, Вы писали:

WH>Начнем с простейшего варианта: Все сидят в транке.
WH>Коммит происходит следующим образом:
WH>Делаем коммит.
WH>Далее говорим смержить все ревизии на которых есть тег trunk. Тк версионник отслеживает что уже было смержено то мержить придется только новые изменения.

Если структура выглядит как-то так:

r3 <trunk>
|
r2 <branch>
|
r1 <trunk>

то совершенно непонятно, что же представляет собой trunk, особенно если первая и третья ревизии не сливаются без конфликтов.

Другое дело, если тег trunk один, и он может двигаться по репозитарию при появлении новых коммитов (и вообще как угодно двигаться).

status=sent (delivered to file: /dev/null)

Re[4]: DVCS Теги vs ...

	От:	WolfHound rsdn
	Дата:	18.03.10 22:35

Здравствуйте, Aquary, Вы писали:

A>Тогда уточни, я правильно ли понял — ты предлагаешь версии складывать на одной ветке (АКА trunk), одну за одной, и при этом всю информацию — какая версия от какой отрощена — сохранять в тегах?
Нет.
Информация о версиях хранится в самих версиях. Те каждая версия знает из какой версии она была порождена и какие версии были в нее смержены.
В тегах лежит информация о том что в этой версии делали. Как я уже писал комментарии, ссылки на тикеты, отчеты билдсервера, принадлежность к той или иной конфигурации,...

... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>

Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн

Re: DVCS Теги vs ...

От:	Gaperton	http://gaperton.livejournal.com
Дата:	18.03.10 22:37
Оценка:	14 (1)

Здравствуйте, WolfHound, Вы писали:

WH>Размышляя на тему DVCS я задумаля, а нужны ли бранчи как отдельная абстракция?
WH>Ведь для организации всего что связано с бранчами достаточно тегов.

Если говорить о DVCS, то в меркуриал, к примеру, бранчей нет. Вернее сказать, бранч — это то же самое, что копия репозитория. И разумеется, тегами ты это не сделаешь.

А вот в Bazaar — бранч и репозиторий это не обязательно одно и то же. Если создать shared repository, то в нем можно делать бранчи. Делается это для того, чтобы экономить дисковое пространство, не копируя все целиком.

Вообще, в DVCS все немного не так. Ты не с subversion лучше преимущества показывай, а с Mercurial. Он попроще, чем git с bazaar.

В целом — как вообще будет работать твоя идея — непонятно. Отличие бранча от ревижна, на который ты собираешься класть тег — в том, что с бранчем связана история изменений, которая учитывается при операции merge. Взять Bazaar — он гораздо интеллектуальнее в плане слияний, чем старые VCS, к которым все привыкли. Как именно будет выполняться merge на одних тегах — мне непонятно. Непонятно ни зачем так делать, ни как оно работать может.

Re[5]: DVCS Теги vs ...

	От:	Aquary	http://scm-notes.blogspot.com/
	Дата:	18.03.10 22:40

Здравствуйте, Roman Odaisky, Вы писали:

RO>А веток-то на самом деле и не существует. Есть только набор ревизий и связи между ними.

А... И ложки тоже никакой нет, Нео.

Конечно же — и ветки и метки — это метаинформация об элементе под контролем версий. Однако сущности это принципиально разные. Только не надо приводить в пример SVN — там меток (т.е. тегов) в привычном понимании просто нет, там тегами названы те же самые бранчи. Переименую дирку tags в stable_branches — ничего не изменится.

RO>Информация же о предках и потомках ревизий хранится в них самих, как сейчас это и происходит в РСКВ.

Вот только каждая новая версия отращивается от предыдущей, базируется на ней. Есть посоледовательность версий: 1 — 2 — 3 — 4. 3 базируется на 1, 4 базируется на 2. Представь себе гемор разработчика при работе с такой чехардой?

RO>Просто человеку, наверное, легче оперировать вроде бы независимыми ветками, чем тегами.

Потому что это принципиально разные вещи.

Re[5]: DVCS Теги vs ...

	От:	Aquary	http://scm-notes.blogspot.com/
	Дата:	18.03.10 22:44

Здравствуйте, WolfHound, Вы писали:

WH>Информация о версиях хранится в самих версиях. Те каждая версия знает из какой версии она была порождена и какие версии были в нее смержены.

Иными словами — версии образуют некое облако и каждая версия имеет инфу о единственном предке, так?

WH>В тегах лежит информация о том что в этой версии делали.

Это уже не просто тег — это т.н. атрибуты. Тут вопросов нет, это есть в любой нормальной системе контроля.

Re[2]: DVCS Теги vs ...

	От:	WolfHound rsdn
	Дата:	18.03.10 23:08

Здравствуйте, Roman Odaisky, Вы писали:

RO>Если структура выглядит как-то так:
хъ
RO>то совершенно непонятно, что же представляет собой trunk, особенно если первая и третья ревизии не сливаются без конфликтов.
Если структура как ты нарисовал то r3 порождена из r1 и как следствие никаких проблем тут нет.

Некое подобие проблемы тут может быть только если мы в таком случае начнем мержить trunk в r6

r3 <trunk>   r5 <trunk>   r6
|            |            |
|            | ___________/
|            |/
r2 <branch>  r4 <trunk> 
|            |
| __________/
|/
r1 <trunk>

В данном случае мы нашли 4 ревизии с тегом trunk.
В этом множестве ревизий находим такие от которых не зависит ни одина другая ревизия в этом множестве. Назавем их головными. В данном случае это у нас r3 и r5.
Далее мержим r5 версионник находит общего предка r4 и проводит операцию мержа. Получаем r7

               ___________r7
              /           |
r3 <trunk>   r5 <trunk>   r6
|            |            |
|            | ___________/
|            |/
r2 <branch>  r4 <trunk> 
|            |
| __________/
|/
r1 <trunk>

Теперь мержим r3. В данном случае общий предок r1 те сливаем изменения которые произошли в r2 и r3. Получаем r8 и вешаем на нее ветку trunk.

 _________________________r8 < trunk>
/                         |
|              ___________r7
|             /           |
r3 <trunk>   r5 <trunk>   r6
|            |            |
|            | ___________/
|            |/
r2 <branch>  r4 <trunk> 
|            |
| __________/
|/
r1 <trunk>

Теперь любой мерж с trunk'ом будет находить только одну головную ревизию r8.

RO>Другое дело, если тег trunk один, и он может двигаться по репозитарию при появлении новых коммитов (и вообще как угодно двигаться).
В том то и смысл что теги никуда не двигаются, а намертво прибиты к тем ревизиям на которые их повесили.

... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>

Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн

Re[3]: DVCS Теги vs ...

	От:	Aquary	http://scm-notes.blogspot.com/
	Дата:	18.03.10 23:14

Здравствуйте, WolfHound, Вы писали:

WH>

...
WH>

Камрад, а ты не ошибся, рисуя структуру версий и их тегов в виде дерева веток?

Re[6]: DVCS Теги vs ...

	От:	WolfHound rsdn
	Дата:	18.03.10 23:26

Здравствуйте, Aquary, Вы писали:

WH>>Информация о версиях хранится в самих версиях. Те каждая версия знает из какой версии она была порождена и какие версии были в нее смержены.
A>Иными словами — версии образуют некое облако и каждая версия имеет инфу о единственном предке, так?
Не единственном. Информация о мержах тоже сохранятеся. В прочем я это уже написал. См выделеное.

WH>>В тегах лежит информация о том что в этой версии делали.
A>Это уже не просто тег — это т.н. атрибуты. Тут вопросов нет, это есть в любой нормальной системе контроля.
Да хоть горшком назови.
Мой поинт в том что на этом механизме можно легко построить все процессы.

... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>

Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн

Re[2]: DVCS Теги vs ...

	От:	WolfHound rsdn
	Дата:	18.03.10 23:26

Здравствуйте, Gaperton, Вы писали:

G>Если говорить о DVCS, то в меркуриал, к примеру, бранчей нет. Вернее сказать, бранч — это то же самое, что копия репозитория. И разумеется, тегами ты это не сделаешь.
Это проблемы меркуриала.

G>В целом — как вообще будет работать твоя идея — непонятно. Отличие бранча от ревижна, на который ты собираешься класть тег — в том, что с бранчем связана история изменений, которая учитывается при операции merge.
Так в моем подходе история мержей связана с ревизией.
Те каждая ревизия знает не только своего предка но и те ревизии которые в нее смержили.
Пройдясь по ссылкам мы легко получаем всю историю мержей.
Чесно говоря не думал что нужно писать это явно.

G>Как именно будет выполняться merge на одних тегах — мне непонятно. Непонятно ни зачем так делать, ни как оно работать может.
Мерж выполняется исключительно на ревизиях. Метки нужны только для того чтобы понять какие ревизии нужно мержить. В самом мерже они не участвуют.

... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>

Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн

Re[7]: DVCS Теги vs ...

	От:	Aquary	http://scm-notes.blogspot.com/
	Дата:	18.03.10 23:58

Здравствуйте, WolfHound, Вы писали:

WH>Не единственном. Информация о мержах тоже сохранятеся. В прочем я это уже написал. См выделеное.

С этим согласен, без инфы о мёржах команду и в особенности интеграторов ждёт геморрой.

Вопрос был — ты действительно предлагаешь сделать просто облако версий?
Только вот в одном из постов представленная иерархия слияния и тегирования в таком облаке сильно напомнила именно дерево веток. Т.е. избавившись семантически от веток — ты, тем не менее, оставил иерархическую структуру, полностью эти ветки повторяющую.

WH>Мой поинт в том что на этом механизме можно легко построить все процессы.

Ну, что сказать — если считаешь, что так лучше — сделай свою VCS, жизнь рассудит

Re[3]: DVCS Теги vs ...

	От:	ilvi
	Дата:	19.03.10 03:13

Здравствуйте, WolfHound, Вы писали:

WH>Некое подобие проблемы тут может быть только если мы в таком случае начнем мержить trunk в r6
WH>

WH>r3 <trunk>   r5 <trunk>   r6
WH>|            |            |
WH>|            | ___________/
WH>|            |/
WH>r2 <branch>  r4 <trunk> 
WH>|            |
WH>| __________/
WH>|/
WH>r1 <trunk>
WH>

WH>В данном случае мы нашли 4 ревизии с тегом trunk.
WH>В этом множестве ревизий находим такие от которых не зависит ни одина другая ревизия в этом множестве. Назавем их головными. В данном случае это у нас r3 и r5.
WH>Далее мержим r5 версионник находит общего предка r4 и проводит операцию мержа. Получаем r7
WH>

WH>               ___________r7
WH>              /           |
WH>r3 <trunk>   r5 <trunk>   r6
WH>|            |            |
WH>|            | ___________/
WH>|            |/
WH>r2 <branch>  r4 <trunk> 
WH>|            |
WH>| __________/
WH>|/
WH>r1 <trunk>
WH>

WH>Теперь мержим r3. В данном случае общий предок r1 те сливаем изменения которые произошли в r2 и r3. Получаем r8 и вешаем на нее ветку trunk.
WH>

WH> _________________________r8 < trunk>
WH>/                         |
WH>|              ___________r7
WH>|             /           |
WH>r3 <trunk>   r5 <trunk>   r6
WH>|            |            |
WH>|            | ___________/
WH>|            |/
WH>r2 <branch>  r4 <trunk> 
WH>|            |
WH>| __________/
WH>|/
WH>r1 <trunk>
WH>

WH>Теперь любой мерж с trunk'ом будет находить только одну головную ревизию r8.

Если я правильно понял твою логику, то описанный тобой случай не возможен. Как только у тебя появится ревизия r5 с тегом trunk, то по приведенной тобой логике она сразу же должна смержится с ревизией r3. В итоге при появлении ревизии r6, она должна будет мержится с результатом мержа r3 и r5.
Или описанный тобой алгоритм не предполагает автоматического выполнения и все действия нужно будет делать ручками?

Re[4]: DVCS Теги vs ...

	От:	WolfHound rsdn
	Дата:	19.03.10 07:16

Здравствуйте, ilvi, Вы писали:

I>Если я правильно понял твою логику, то описанный тобой случай не возможен. Как только у тебя появится ревизия r5 с тегом trunk, то по приведенной тобой логике она сразу же должна смержится с ревизией r3. В итоге при появлении ревизии r6, она должна будет мержится с результатом мержа r3 и r5.
Нет. Версионник распределенный.
Те Петя в офисе сделал r3.
Вася в парке на своем ноутбуке сделал r5.
Далее эти ревизии по электронной почте попали к Вове который сидит дома и работает над r6.

Но даже если они все будут сидеть в офисе есть не нулевые шансы что у транка окажутся две головы.

I>Или описанный тобой алгоритм не предполагает автоматического выполнения и все действия нужно будет делать ручками?
При мерже могут быть конфликты и его по любому нужно делать руками.

... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>

Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн

Re[8]: DVCS Теги vs ...

	От:	WolfHound rsdn
	Дата:	19.03.10 07:16

Здравствуйте, Aquary, Вы писали:

A>Вопрос был — ты действительно предлагаешь сделать просто облако версий?
Да.

A>Только вот в одном из постов представленная иерархия слияния и тегирования в таком облаке сильно напомнила именно дерево веток. Т.е. избавившись семантически от веток — ты, тем не менее, оставил иерархическую структуру, полностью эти ветки повторяющую.
Дело в том что если ревизия хранит ссылку на родителя и информацию о мержах то такая картинка получается автоматически.

... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>

Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн

Re[3]: DVCS Теги vs ...

	От:	Roman Odaisky
	Дата:	19.03.10 07:33

Здравствуйте, WolfHound, Вы писали:

WH>Если структура как ты нарисовал то r3 порождена из r1 и как следствие никаких проблем тут нет.

WH>Некое подобие проблемы тут может быть только если мы в таком случае начнем мержить trunk в r6
WH>

WH>r3 <trunk>   r5 <trunk>   r6
WH>|            |            |
WH>|            | ___________/
WH>|            |/
WH>r2 <branch>  r4 <trunk> 
WH>|            |
WH>| __________/
WH>|/
WH>r1 <trunk>
WH>

WH>В данном случае мы нашли 4 ревизии с тегом trunk.
WH>В этом множестве ревизий находим такие от которых

Даже если не смотреть на ответвления (r4—r6), получается, что r1 и r3 в trunk входят, а r2 — нет. Что окажется у того, кто сделает checkout trunk? Объединение r1 и r3, которое может вызвать конфликты? Если он их сам разрешит, то куда положит коммит с нужными изменениями? А что, если потом на r2 тоже повесят тег trunk?

status=sent (delivered to file: /dev/null)

1 2 3