DVCS

[kika]

Все время хотел спросить у облака, но забывал. Вот есть у нас распределенные системы контроля версий, меркурий там, darcs, базар в натуре, ну и т.д., в ассортименте, короче. Я всегда слово "распределенный" воспринимал как "децентрализованный", то есть, применительно к VCS это значит что у нас нету в конторе "cvs сервера", а есть распределенная система контроля версий. Тем не менее, у нас, например, несмотря на распределенную команду и использование hg, сервер таки есть. И все туда пушают и оттуда пуллают.
Это потому что DVCS никакие на самом деле не D, или потому что мы старые заскорузлые козлы, которые просто променяли старый привычный cvs на новомодное поделие, куда коммитить можно локально, а все потом будут расхлебывать?

Кагбе, интуитивно, я бы подумал, услышав слово DVCS, что эта такая система, куда я коммичу (или делаю пуш) а оно само разъезжается по остальному облаку юзеров. А сервер(а) нужен только как бакап и/или чтобы в облаке всегда была как минимум одна нода в онлайне.

Comments

[lionet.livejournal.com]

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

[jsn.livejournal.com]

У нас вот в нашем игрушечном опенсорсе заметное количество случаев pull / merge -- из всяких левых реп. Ну, то есть, захотел человек законтрибьютить без коммит бита или кто-то из core хочет пошарить какой-нибудь экспериментальный патчсет -- коммитят к себе, на github, или в самостоятельно захощенную репу, или локально, если внешний ip есть. выдают потом народу git url, и вперёд.

Т.е. сервера помимо главного вполне мелькают, в качестве endpoint-ов для peer-to-peer communication -- D вполне себе. Хотя контрибьюторов у нас полтора калеки.

[msh.livejournal.com]

Насколько я понимаю, главное назначение DVCS в совеременном виде - это борьба с говнистостью opensource developers. С DVCS каждый может коммитить в свою песочницу и не сраться по поводу каждого коммита со всеми подряд, а только изредка когда мерджат.

[dottedmag.livejournal.com]

Distributed, а не Decentralized.

Собственно, придумывали их для трёх вещей: локальные коммиты/бранчи; возможность выстроить workflow так, как удобно, а не так, как навязывает инструмент; возможнуть без геморроя полностью отфоркнуться (FSF).

Так что облачность возможна (e.g. gittorrent), но необязательна, ибо является одним из workflow, не всегда применимым (см. например несколькоуровневый patchflow для линукса).

[kika.livejournal.com]

Я не скажу за всю сеть, но конкретно в Hg периодически их синхронизировать это Адъ. Причем пропорциональный кубу длины периода.

[kika.livejournal.com]

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

[kika.livejournal.com]

Зато срач в момент мерджа равен не сумме срачей по мелочи, а произведению :-)

[kika.livejournal.com]

Про форки и локальные коммиты согласен, они в D удобные. А воркфлоу удобные только те, которые не D.

[dottedmag.livejournal.com]

От проекта очень сильно зависит, какой workflow выбрать, так что жёстко вписывать их в VCS не стоит.

Т.о. несколько готовых workflow вместе с DVCS (см. например новый Bazaar) - это хорошо и полезно, но необязательно: всё равно не-D workflow возникнет без поддержки инструментов, а простов выписанный в виде документации разработчикам к проекту.

Возвращаясь к линуксу: очень сложно было бы предвидеть, что git породит текущую схему движения патчей и застолбить её в инструменте.

[kika.livejournal.com]

D - это не воркфлоу, это характеристика (одна из) его. И наличие нормального D может улучшить любой воркфлоу, кроме разве что самых примитивных. Да и примитивные, в общем тоже.
Вот пример: у нас есть девелоперы, и есть hg сервер куда все пушают локальные коммиты. Форков нет, локальных бранчей минимум. Но из-за того что нет нормального облака получается ручная операция затолкнуть на сервер и перед коммитов высосать с сервера апдейт. Посольку это не атомарная операция, то возможны конфликты на ровном месте. Учитывая еще и долбоебизм ртутного мерджа...
А вот если у нас для коммитов XMPP, кхе-кхе :-) да еще и со store-and-forward...

[dottedmag.livejournal.com]

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

Я не зря упомянул Bazaar, загляни в их доку на предмет centralzied workflow.

[jsn.livejournal.com]

я, наверное, опять не понял, чего ты хочешь (как и в случае с cloud ux or something). откуда тут partitioning? и как выглядел бы D?