tag:blogger.com,1999:blog-3474485280270816955.post7170838218555015844..comments2022-04-08T04:05:24.099-07:00Comments on Brain IT!: Введение в Mercurial. Часть 1. Распределенные системы контроля версий (DVCS).Гиркин Михаилhttp://www.blogger.com/profile/16452424330632615848noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-3474485280270816955.post-42803162318291876142010-03-26T03:37:49.619-07:002010-03-26T03:37:49.619-07:00Лично меня hg привлек именно локальностью коммитов...<i>Лично меня hg привлек именно локальностью коммитов - я теперь вряд ли смогу сломать код в общем репозитории, и у меня теперь есть возможность делать частые коммиты, в отличие от централизованных систем.</i><br /><br />Возможность делать частые коммиты при наличии быстрого канала ограничивается только локальными политиками по работе с ветвями. Если ограничений на ветви нет, то можно делать частые коммиты в свою ветвь в централизованном репозитории или вообще всегда вести разработку в ветви — тогда и сломать ничего не удастся.<br /><br />Меня больше интересует ситуация с tree conflict в hg и git. Самое неприятное для меня ограничение svn — появление tree conflicts при рефакторинге кода в ветви, когда рефакторинг связан с перемещениями и переименованиями файлов. Вот что, например, произойдет в hg, когда я буду мержить ветвь, в которой были переименования, в основную ветвь, в которой те же файлы оказались отредактированными?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3474485280270816955.post-50066008174900834822010-03-23T02:54:52.744-07:002010-03-23T02:54:52.744-07:00Наличие локальных коммитов не приводит к появлению...Наличие локальных коммитов не приводит к появлению неконтролируемых ветвей разработки. Никто же не запрещает часто пушить код в общедоступный репозиторий.<br />В сравнении с последними версиями Svn (1.6), ветвления практически аналогичны. Единственно - количество телодвижений которые нужно совершить в git и в hg меньше.<br />Лично меня hg привлек именно локальностью коммитов - я теперь вряд ли смогу сломать код в общем репозитории, и у меня теперь есть возможность делать частые коммиты, в отличие от централизованных систем.<br />Да и скорость работы тоже впечатляющая. Даже по сравнению с быстрым svn.Гиркин Михаилhttps://www.blogger.com/profile/16452424330632615848noreply@blogger.comtag:blogger.com,1999:blog-3474485280270816955.post-63803066001159413662010-03-22T19:46:18.149-07:002010-03-22T19:46:18.149-07:00Я очень внимательно присматриваюсь к DVCS, именно ...Я очень внимательно присматриваюсь к DVCS, именно поэтому стараюсь читать появляющиеся отзывы их счастливых пользователей.<br /><br />Децентрализованность дает разработчикам большую гибкость и мобильность. В то же время, легкость локальных коммитов приводит к появлению неконтролируемых локальных ветвей разработки, что не соответствует нашему внутреннему workflow. Мы постояно ветвимся и каждый может свободно экспериментировать в своих бранчах, но имеющаяся у всех возможность наблюдать за ходом разработки во всех ветвях всем кажется очень полезной. В конце концов бранч можно просто удалить, а занимаемое репозиторием дисковое пространство не является таким уж дорогим ресурсом (и не так уж часто нет доступа к репозиторию). Так что в этом смысле идея DVCS мне как раз не очень нравится.<br /><br />Поддержку ветвлений в hg и git все постоянно хвалят, но почему-то сложно найти их аккуратное сравнение с современным состоянием svn. Все говорят «Пробуйте!», но внятно объяснить почему-то не хотят. hg я пробовал локально и особого удобства в выполнении слияний не заметил.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3474485280270816955.post-14354952498183638242010-03-22T01:19:16.114-07:002010-03-22T01:19:16.114-07:00С этим и в Меркуриал и в Гит все в порядке.
Заметь...С этим и в Меркуриал и в Гит все в порядке.<br />Заметьте, я никогда не говорил, что SVN - полный отстой, я достаточно адекватен, чтобы понимать, что это весьма неплохая система контроля версий. Однако количество телодвижений, которое нужно совершить для организации ветви, а потом для её слияния значительно больше чем в Mercurial и Git.<br />DVCS - это просто достаточно большой шаг вперед, по сравнению с централизованными системами. И этот шаг вперед - это не только отличная поддержка ветвлений, но и множество других хороших вещей, которые в централизованных системах нереализуемы ввиду их концепции. Локальные коммиты, возможность поэкспериментировать в своем репозитории, и уже потом принимать решение - заливать все в общий, или нет. Это просто удобно. Попробуйте!<br />И ладно бы, если бы они были платные, но это же не так...Гиркин Михаилhttps://www.blogger.com/profile/16452424330632615848noreply@blogger.comtag:blogger.com,1999:blog-3474485280270816955.post-43753380544712317812010-03-21T18:30:08.292-07:002010-03-21T18:30:08.292-07:00Немного подумав, я вроде бы понял, что Вы имели в ...Немного подумав, я вроде бы понял, что Вы имели в виду под фразой «до версии 1.6 не было средств работы с перемещенными/переименованными файлами». Вероятнее всего, имелось в виду отслеживание случаев т.н. tree conflicts при слиянии векток после перемещения/переименования в них файлов. Это действительно добавлено в версии 1.6. Кстати, как с этим (слияние изменений в переименованном файле) дела в hg?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3474485280270816955.post-32764247971589069552010-03-20T13:55:42.296-07:002010-03-20T13:55:42.296-07:00Да, и еще. В версии 1.6 не было никаких изменений,...Да, и еще. В версии 1.6 не было никаких изменений, связанных с переименованием файлов. Переименования и перемещения вполне корректно (с сохранением истории файла) обрабатывались еще в версии 1.4, насколько я помню. Если я не прав, то интересует пруфлинк.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3474485280270816955.post-86579992887317784162010-03-20T13:51:56.962-07:002010-03-20T13:51:56.962-07:00Правда до версии 1.5 они вызывали мегааллергию, а ...<i>Правда до версии 1.5 они вызывали мегааллергию, а до версии 1.6 не было средств работы с перемещенными/переименованными файлами.</i><br /><br />Да, до версии 1.5 (вышедшей, кстати, уже почти 2 года назад) в svn не было т.н. merge tracking-а и использование веток было проблемой. Но вряд ли стоит сравнивать hg с тем svn, каким он был 2 года назад. А вот сравнение текущего положения дел с ветками в svn и hg было бы весьма интересным. Впрочем, кажется, что никакого существенного различия тут уже нет.<br /><br /><i>в меркуриал эти операции значительно проще и быстрее</i><br /><br />Вся сложность ветвлений состоит в слиянии при наличии конфликтов. Что-то я не слышал про существенный прогресс в этой области.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3474485280270816955.post-22424081493281012272010-03-20T10:39:52.296-07:002010-03-20T10:39:52.296-07:00" Постоянно использую бранчи в SVN именно как..." Постоянно использую бранчи в SVN именно как повседневную операцию (почти вся разработка протекает в бранчах) и не испытываю никаких проблем при слиянии. Что я делаю не так? "<br />Вы все делаете так. И, действительно, пользоваться бранчами в SVN вполне возможно. Правда до версии 1.5 они вызывали мегааллергию, а до версии 1.6 не было средств работы с перемещенными/переименованными файлами.<br />И все это приводит к написанию вот таких гайдов по мержингу: http://habrahabr.ru/blogs/development_tools/57591/ . Но бранчи там есть, и ими действительно можно пользоваться, и с версии 1.6 с ними все так.<br />Дело тут в том, что в гит и в меркуриал эти операции значительно проще и быстрее. Сравните это с переездом с CVS на SVN. Когда вы освоите workflow, который предлагает вам Mercurial или Git - вы вряд ли с большим желанием вернетесь обратно.Гиркин Михаилhttps://www.blogger.com/profile/16452424330632615848noreply@blogger.comtag:blogger.com,1999:blog-3474485280270816955.post-40482987848725823592010-03-20T10:20:41.703-07:002010-03-20T10:20:41.703-07:00Есть конечно бранчи, но в svn это довольно жесток...<i>Есть конечно бранчи, но в svn это довольно жестокая штука, по крайней мере судя по отзывам использующих людей.<br /><br />/.../ ветвление это повседневная операция, это в принципе основа контроля версий в данном случае. И реализована она абсюлютно логично и понятно, и действительно проста в использовании.<br /><br />Для меня решающим фактором при принятии решения о переходе на Mercurial стали именно локальные коммиты /.../ и настолько мощная поддержка ветвления.</i><br /><br />Постоянно использую бранчи в SVN именно как повседневную операцию (почти вся разработка протекает в бранчах) и не испытываю никаких проблем при слиянии. Что я делаю не так?<br /><br />Что конкретно не так с ветвлением в SVN с Вашей точки зрения? А то уже поднадоела голословная ругань в адрес SVN от людей, которые «слышали отзывы».Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3474485280270816955.post-49479468135119176242010-03-17T07:36:12.841-07:002010-03-17T07:36:12.841-07:00> решающим фактором при принятии решения о пере...> решающим фактором при принятии решения о переходе на Mercurial стали именно локальные коммиты ... и настолько мощная поддержка ветвления<br /><br />Я работаю не с мерком, а с гитом. Для меня важен только первый фактор, подозреваю из-за того, что масштабы проекта не настолько велики. И что-то мне кажется, что локальные коммиты можно было бы реализовать и в централизованных сквAnonymoushttps://www.blogger.com/profile/05687833868427366186noreply@blogger.comtag:blogger.com,1999:blog-3474485280270816955.post-17131156652735394392010-02-11T07:19:08.288-08:002010-02-11T07:19:08.288-08:00>При этом это не ветвление Subversion, это дейс...><i>При этом это не ветвление Subversion, это действительно настоящее, удобное и понятное ветвление и слияние.</i><br /><br />Не могли бы вы подробнее рассказать про недостатки ветвления в Subversion?<br /><br />У меня весьма наивное представление о ветвлении в VCS (как централизованных, так и распределённых) — просто не так уж часто приходилось ветвлением/слиянием заниматься.<br /><br />Ветвление, afaik, это способ изоляции (новой недоделанной фичи, экспериментов в песочнице отдельного разработчика, etc), при сохранении непрерывного версионирования. Subversion обеспечивает это с помощью механизма ветвей. Mercurial обеспечивает это с помощью клонов репозитория и внутрирепозиторных ветвей.<br /><br />Предположим, нет необходимости работать оффлайн, связь с центральным сервером хорошая, машины быстрые.<br /><br />В этих условиях — какие есть преимущества у механизмов ветвления Mercurial'а по сравнению с таковыми у Subversion'а?<br /><br />Распространённый аргумент, дескать, необходимость мерджа может помешать коммиту, не катит — у разработчика может быть приватная ветвь; sharing кода происходит не через коммиты рабочей копии в общую ветку, а через вливание своей приватной ветки в общую.<br /><br />Заранее благодарен за ответ!Anonymousnoreply@blogger.com