Comments 18
и в чем мораль?
Еще один интересный вид VCS — darcs. Если в упомянутых DVCS при получении любой ветки ты получаешь все изменения от корня до выбранной вершины, то в darcs репозиторий — это просто набор матчей, и при checkout можно выбрать одни патчи и пропустить другие. Ограничением являются только зависимости между патчами.
Там понятие версии еще более расплывчатое.
Не уверен в удобстве такого подхода для больших проектов и команд (да и тормозит на больших объемах), но для небольших — очень удобно.
Там понятие версии еще более расплывчатое.
Не уверен в удобстве такого подхода для больших проектов и команд (да и тормозит на больших объемах), но для небольших — очень удобно.
Иллюстрации классные. Без шуток. Такие аккуратные кружки, в меру круглые, и каждый уникален. Очень приятно смотрится и такой подход практически не встречается при этом.
Очень доступно — полезный топик!
на самом деле, не совсем понятна разницу между работой в 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 в компании было вбухано годовой бюджет нашего офиса, потому им легче было нас разогнать чем что-то менять.
Кстати когда я готовил обзор возможных альтернатив для руководства то не увидел сильных преимуществ 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% от всех, противоречий тут нет :)
«99,44% разработчиков используют SCM-средства, основанные на линейной модели ведения истории (да, я собирал такую статистику)»
Здесь имеется в виду значение «make up — 4) придумывать, выдумывать, сочинять».
Здесь имеется в виду значение «make up — 4) придумывать, выдумывать, сочинять».
у нелинейных систем есть афигенный бонус — можно отъехать назад до отпочкования ветки (если основная тоже ушла вперёд) потом переехать по основной ветке в конец и снова налепить по порядку все изменения. Для базара этим легко и непринужденно занимается плагин rebase. Интересно, что если будут конфликты — на них придётся потратить столько же времени сколько на мержинг, но при этом не все сразу. И плюс — конфликты в таких случаях хороший повод уточнить кто чего в проекте делает.
Если же этого не сделать то получится так называемый self-merge. Т.е. свой бранч девелоперу надо будет смержить с тем же бранчем общим. Вот это как раз путанницу и делает.
Вот пример:
Обратите внимание на 481 ревизию — на ней на самоми деле остановилась жизнь старого бранча. А в локальном бранче — ещё хуже. Когда отпочковался от 480, там было 4 коммита (т.е. до 484). А после вливания в транк все оказалось в том же бранче но в 482. Если бы я в тот момент использовал rebase — получилось бы с 480 по 485, линейно и предельно просто.
Если же этого не сделать то получится так называемый self-merge. Т.е. свой бранч девелоперу надо будет смержить с тем же бранчем общим. Вот это как раз путанницу и делает.
Вот пример:
Обратите внимание на 481 ревизию — на ней на самоми деле остановилась жизнь старого бранча. А в локальном бранче — ещё хуже. Когда отпочковался от 480, там было 4 коммита (т.е. до 484). А после вливания в транк все оказалось в том же бранче но в 482. Если бы я в тот момент использовал rebase — получилось бы с 480 по 485, линейно и предельно просто.
Sign up to leave a comment.
DVCS and DAGs