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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

...

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

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

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

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

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

...

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

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

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

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

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

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

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

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

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

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

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

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

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

o_O

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

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

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

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

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

Двухуровневый комит с быстрым просмотром "старшим товарищем" кстати очень полезная штука, в том числе и для воспитания. Впрочем 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 проще и красивее именно для добавления новых фич.

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

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

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

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

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

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

:D

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

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