Новая система управления версиями от разработчиков Ubuntu

> Как я уже писал, оно(для меня лично) оправдано при многоуровневом коммите, что есть редкость даже очень крупных проектов.

Ну вот жизненный пример с моей нынешней работы: есть сайт на django, над ним работают два-три программиста и один дизайнер. Дизайнер не то из Перу, не то из Аргентины, тупой как дерево, еле-еле научили его делать bzr commit. Естественно, все его правки, прежде чем попасть на живой сайт, проходят через кого-нибудь из программистов. Вот и многоуровневый коммит. А если он натворит чего-то не того, всегда можно откатить его ветку к рабочей ревизии.

>В ряде случаев децентрализованная система гораздо удобнее.

Угу. Когда надо наплодить кучу несовместимых между собой веток :) Децентрализованная система пригодна _исключительно_ в тех случаях, когда каждый из разработчиков работает строго над своим куском кода и очень оперативно реагирует на те или иные запросы других участников. Для жёсткой коммерческой конторы годится, для типичного опенсорс-коммьюнити - смерть.

> При работе с Subversion всегда работаю с центральным репозитарием.

Ну, если предполагается, что ващевсегда единый репозиторий и ващевсе имеют к нему доступ и могут содавать ветки, то у DVCS остается одно преимущество - нормальный граф версий и нормальный merging (когда там выходит SVN с merge tracking? 8))

> Для жёсткой коммерческой конторы годится, для типичного опенсорс-коммьюнити - смерть.

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

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

Вот для мелких как раз они и удобны :) У меня, скажем, вообще /etc кидается в git :D

>> В ряде случаев децентрализованная система гораздо удобнее.

> Угу. Когда надо наплодить кучу несовместимых между собой веток :)

А куча рабочих копий для этой же цели не подойдет? :D

> Вот для мелких как раз они и удобны :)

И Линукс мелкая поделка? :)

>Вызывающе неверная информация. Если ты хочешь сделать небольшой патч для опенсорсного проекта, с DVCS это гораздо проще

Вот именно, опять та ситуация, про которую я говорил.

DVCS провоцируют программистов не постоянно править что-то по мелочи, делая как можно более частый синки с основным репозиторием, а "до упора" работать у себя, с локальной копией, потом разом вываливая на коллег тонны правок... При чём, если, не дай Бог, его работа пересечётся с работой другого коллеги - потом море работы по синхронизации их изменений.

Это решается при наличии очень жёсткой дисциплины в команде, но это в опенсорскоммьюнити - большая редкость.

Для себя в одиночку я предпочту DVCS по ряду причин, а работать в команде с толпой недисциплинированных студентов - упаси боже даже CVS заюзать, они там бранчей наплодят, нет, только SVN, в которой никто ничего себе отстрелить не сможет :)

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

А вот это уже 4.2 в особо циничной форме.

>И Линукс мелкая поделка? :)

Там тот самый упомянутый мной случай жёсткого контроля и дисциплины. Ещё Xorg туда же возьмите. Таких проектов - по пальцам одной руки пересчитать можно. Я же говорю про основную массу средних и крупных проектов.

...

Блин, у нас в L2Fortress умудрялись огребать кучу конфликтов даже на SVN. Мне просто страшно представить, что было бы с проектом, будь он на DVCS. И это при какой-то полудюжине активных разработчиков и дюжины редких коммитеров...

>А вот это уже 4.2 в особо циничной форме.

Это трёхгодичная практика руководства распределённой работы опенсорс команды.

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

> локальный коммит?

+ клонирование репозиториев и переливание изменений из одного в другой

> + клонирование репозиториев и переливание изменений из одного в другой

клонировани - это всего лишь деталь реализации, а переливание - конечно, как-то же надо отдавать изменения другим.

Ну так клонирование - это и есть переливание. По-моему, этот обмен изменениями и есть ключевая фича DVCS.

>так что корни ее не в DVCS, а в человеческих привычках

Вот в этом-то и беда. Я же не говорю, что DVCS не может чего-то, что можно в CVCS. Нет. DVCS всем прекрасны и всем замечательны, по функционалу уделывают централизованные системы и всё такое...

...

Но есть человеческий фактор.

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

Если в команде хорошая дисциплина и высокий уровень ответственности - то DVCS хороши и прекрасны. Если команда - это случайное скопление раздолбаев, то DVCS - это 50% времени ведущих программистов, затраченное на расхлёбывание конфликтов и глюков, совершенных менее ведущими, но очень активными коммитерами :)

> Ну так клонирование - это и есть переливание.

ИМХО, клонирование - это всего лишь способ получить рабочую копию + метаданные, указывающие место этой копии в глобальном графе версий; Полная история не является необходимо. ЕМНИП, OpenCM полную историю не клонировала, но вполне работала :)

> этот обмен изменениями и есть ключевая фича DVCS.

обмен изменениями - да, но не _этот_ (то есть не клонирвание, а push/pull, которые "просто" транспортируют узлы графа версий, созданные локальными коммитами).

> всегда найдётся идиот, который сделает коммит, который потом другому придётся неделю расхлёбывать.

staging-репозиторий (многоуровневый коммит, упоминавшийся выше) проще создать в DVCS.

> Если команда - это случайное скопление раздолбаев

то я не понимаю, причем здесь то, что "DVCS провоцируют программистов не постоянно править что-то по мелочи, делая как можно более частый синки с основным репозиторием, а "до упора" работать у себя" 8) Раздолбай может точно так же работать с обычной локальной рабочей копией, разве нет?

Кто интересуется чем DVCS лучше обычных, посмотрите интересное кино на Youtube, правда оно на английском. Там Линус Торвальдс рассказывает про Git. Очень позновательно. Местами не мог сдержать смех. Сам я пользовался 5 разными централизованными VCS ( MS VSS, Starteam, PVCS, CVS и Surround SCM ), так что есть с чем сравнивать. http://www.youtube.com/watch?v=4XpnKHJAok8.

>staging-репозиторий (многоуровневый коммит, упоминавшийся выше) проще создать в DVCS.

Проще. Но кто потом будет это всё разгребать? :) Это минус рабочее время нормальных девелоперов.

>Раздолбай может точно так же работать с обычной локальной рабочей копией, разве нет?

По крайней мере конфликты ему придётся самому разруливать, ибо при их наличии он просто закоммитить не сможет свои наработки. В результате работа "продвинутой" части уменьшается с "ликвидация конфликтов + проверка" до "проверка". Как следствие, "недисциплинированного разработчика" начинает доставать писать огромные коммиты с последующей мучительной синхронизацией и стимулирует написание мелких модификаций, которые проверяются намного легче. Начинает вырабатываться нормальный стиль работы.

>>staging-репозиторий (многоуровневый коммит, упоминавшийся выше) проще создать в DVCS.

>Проще. Но кто потом будет это всё разгребать?

o_O

Так, вопрос ребром - вы пробовали использовать DVCS в L2Fortress? Если да, то какую, сколько времени, и как был организован процесс?

>>Раздолбай может точно так же работать с обычной локальной рабочей копией, разве нет?

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

Может я, ветеран SVN, уже в маразме, но svn resolve замечательно помечает файл с конфликтами как "конфликт разрулен" :D или ваши девелы настолько раздолбаи, что не знают этого? 8)

И еще - не знаю, как там у вас в git, а у нас в Mercurial можно просто запретить коммиты, создающие новую голову.

Ага, а SVN некомпилящийся, или криво замерженый код разгильдяи не положат? Помогает только регулярный code review и втыки.

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

> Это стандартный цикл разработки:

Я не то хотел сказать, хотел сказать, что в DVCS проще поддерживать параллельные ветки. Например, взяли базовую версию 1.0, в ветку original, а сами в стволе делаем свои фичи. Вышла 2.0, обновили ветку, портировали изменения 1.0->2.0 из original в свой ствол, слив свои изменения с 1.0 и чужие 1.0->2.0.

Просто в DVCS бывает cherrypicking и сливание изменений. То же сливание изменений из своей ветки в upstream выполняется простым git rebase, при этом твои изменения (1.0- >1.0') автоматом применятся к обновлённой upstream (1.0-2.0-2.0'). Если ты делал feature branch, то вряд ли твои изменения накладываются на изменения в upstream, поэтому скорее всего конфликтов не будет, и слить можно автоматически.

При ручном merge придется сверять все изменения вручную, 3-way: у тебя есть свои изменения от базовой, изменения базовой в upstream, и их надо слить, разрулив конфликты. В принципе, то же, но в профиль (только в другом порядке), но rebase проще и красивее именно для добавления новых фич.

>Так, вопрос ребром - вы пробовали использовать DVCS в L2Fortress?

Я не самоубийца :) Не обязательно прыгать с седьмого этажа, чтобы понять, что это - опасно для жизни.

>И еще - не знаю, как там у вас в git, а у нас в Mercurial можно просто запретить коммиты, создающие новую голову.

Примечательно, но ты просто не читал мои сообщения.

>Ага, а SVN некомпилящийся, или криво замерженый код разгильдяи не положат? Помогает только регулярный code review и втыки.

Именно так. Но в DVCS возможно то же самое + лишняя головнная боль от большой локальной работы.

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

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

>>Так, вопрос ребром - вы пробовали использовать DVCS в L2Fortress?

>Я не самоубийца :)

:D

> Примечательно, но ты просто не читал мои сообщения.

Что, совсем? o.O