Как стать автором
Обновить

Комментарии 18

Мораль в том, что не все так просто и хорошо, как может показаться при первом взгляде на распределенные СКВ. Есть тут свои подводные камешки, на которые и указывает автор статьи.
Еще один интересный вид VCS — darcs. Если в упомянутых DVCS при получении любой ветки ты получаешь все изменения от корня до выбранной вершины, то в darcs репозиторий — это просто набор матчей, и при checkout можно выбрать одни патчи и пропустить другие. Ограничением являются только зависимости между патчами.
Там понятие версии еще более расплывчатое.
Не уверен в удобстве такого подхода для больших проектов и команд (да и тормозит на больших объемах), но для небольших — очень удобно.
Да, так и есть. И Эрик Синк (в комментариях к этой же статье) пообещал рано или поздно про darcs поподробнее написать. Как знать, может и что-то интересное напишет.
Иллюстрации классные. Без шуток. Такие аккуратные кружки, в меру круглые, и каждый уникален. Очень приятно смотрится и такой подход практически не встречается при этом.
Очень доступно — полезный топик!
на самом деле, не совсем понятна разницу между работой в DAG и работе в DVCS активно используя ветки.
немного не по теме: пессимистичная блокировка в его Vault-е — ужасное решение по-умолчанию. Очень часто у нас возникала нелепая проблема — кто-то нажал check out вместо get latest version и залочил файл. неудобно.
Всё конечно класно, но последний отчёт который я видел кажется был за 2007-й год и там 60% или более комерческих систем контроля версий занимает монстр под именем Rational ClearCase и там как раз нелинейная история. Потому «И это хорошее обоснование того, что 99,44% раз­ра­бот­чи­ков используют SCM-средства, основанные на линейной модели ведения истории (да, я собирал такую статистику).» это непонятно откуда взятые данные. Правда и та что несмотря на уродскую реализацию продажники IBM могут толкать это гуано лучше чем вся остальная индустрия вместе взятая. А в открытых разработках Subversion пока доминирует, хотя некоторый тренд на распределённые системы уже имеется, но пока лидер SourceForge не предложит второй вариант в качестве системы контроля версий то думаю Subversion из педестала не подвинут еще как минимум 2 года.
Кстати когда я готовил обзор возможных альтернатив для руководства то не увидел сильных преимуществ CodeGear по сравнению с имеющимся Perforce. Я присматривался к BitKeeper, всё таки система прошла обкатку с 1000+ разработчиков, большим количеством суб-проэктов. Но к сожалению к тому времени в развёртывание ClearCase в компании было вбухано годовой бюджет нашего офиса, потому им легче было нас разогнать чем что-то менять.
SourceForge? Слышал, что у них уже и git, и mercurial поддерживается.
Я ошибался. Судя по этому apps.sourceforge.net/trac/sourceforge/wiki/WikiStart у них уже полный набор: SCM (source code management) services: Subversion, Git, Mercurial, Bazaar, CVS. Хотя статистики по существующим проэктам сколько из них меняют систему контроля версий. Да и непростое это дело и причины должны быть серёзные.
В оригинале автор как раз иронизирует по поводу этих процентов (примерно как «ну да, я придумал этот процент»). Хотя в принципе 60% коммерческих систем вполне может соответствовать 99,44% от всех, противоречий тут нет :)
Дело в том что у ClearCase как раз нелинейная история.
Я о том, что с логической точки зрения это не противоречит процентам, даже если они взяты с потолка.
«99,44% разработчиков используют SCM-средства, основанные на линейной модели ведения истории (да, я собирал такую статистику)»
Здесь имеется в виду значение «make up — 4) придумывать, выдумывать, сочинять».
Да, спасибо большое за поправку, не доглядел.
у нелинейных систем есть афигенный бонус — можно отъехать назад до отпочкования ветки (если основная тоже ушла вперёд) потом переехать по основной ветке в конец и снова налепить по порядку все изменения. Для базара этим легко и непринужденно занимается плагин rebase. Интересно, что если будут конфликты — на них придётся потратить столько же времени сколько на мержинг, но при этом не все сразу. И плюс — конфликты в таких случаях хороший повод уточнить кто чего в проекте делает.

Если же этого не сделать то получится так называемый self-merge. Т.е. свой бранч девелоперу надо будет смержить с тем же бранчем общим. Вот это как раз путанницу и делает.

Вот пример:


Обратите внимание на 481 ревизию — на ней на самоми деле остановилась жизнь старого бранча. А в локальном бранче — ещё хуже. Когда отпочковался от 480, там было 4 коммита (т.е. до 484). А после вливания в транк все оказалось в том же бранче но в 482. Если бы я в тот момент использовал rebase — получилось бы с 480 по 485, линейно и предельно просто.
Да, если же этого не делать и злоупотреблять, то при возрастании кол-ва разработчиков все быстро преврещается в похожую картинку автора:

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории