В защиту Bazaar
Сегодня прочел в сети о том, что Bazaar говно. :)
В сети должно быть равновесие. :) Поэтому, из соображений благодарности к его авторам, я расскажу о том, что Bazaar - лучшая DVCS для человека, который хочет использовать все плюсы DVCS, и одновременно не забивать себе голову ненужной хуйней ерундой. Я весной 2010 года выбирал между хорошо знакомым ( Read more... )
В сети должно быть равновесие. :) Поэтому, из соображений благодарности к его авторам, я расскажу о том, что Bazaar - лучшая DVCS для человека, который хочет использовать все плюсы DVCS, и одновременно не забивать себе голову ненужной хуйней ерундой. Я весной 2010 года выбирал между хорошо знакомым ( Read more... )
Так что по первому пункту - hgtk commit (hgtk push и прочее до кучи).
По второму - лично мне бранчи "на месте", а не в соседнем каталоге, сейчас удобнее (переключился - и всё работает). Ну и сама концепция named branches в репозитории - они удобны для feature-branch.
Но на самом деле просто с hg сразу стал работать, а с bzr пришлось разбираться.
Reply
В смысле, путей не надо перенастраивать, так? Ну да, есть такое дело.
С другой стороны, почему бы не писать так, чтобы работоспособность не зависела от имени директории?
И кроме того, разве это не удобно - одновременно видеть все свои бранчи?
Reply
Не надо копировать файлы данных и настроек.
Одновременно видеть бранчи - как правило, мне не требуется. Но если надо - никто не мешает сделать hg clone/hg update (кстати, меркуриал вроде тоже clone оптимизирует хардлинками) или hg archive (чтобы получить срез).
В общем, я раньше жил с CVS-ной идеологией, перешёл на hg-шные named branches - в целом понравилось.
Идеология branch==clone мне понятна (и, естественно, поддерживается hg), но не нравится тем, что когда я делаю pull - я не получаю все бранчи.
Reply
Reply
И, напротив, неудобно помнить, у кого какие бранчи есть.
Собственно, вопрос в сценарии использования.
Reply
bzr-colo не подошел по функциональности или по каким другим причинам?
Reply
Главное-то - именно первое. Начал с bzr, потом попробовал hg - и понравилось больше (бранчи в bzr показались сложнее).
Reply
Reply
Вот в named branches и правда не сразу въехал, и претензию, что они прилеплены поверх, понимаю =).
Reply
При простом применении, bzr полностью идентичен hg. _Полностью_. Ваще нет отличий.
Различие начинается с использованием shared repository в bazaar и named branch в hg. shared repository - аналог этого понятия в hg отсуствует, и с него реально начинается разница. Shared repository - это просто папка, находясь в которой бранчи-репозитории бранчуются-клонируются умопомрачительно быстро, ибо разделяют, а не копируют, историю. :)
И все. Ну вот что тут сложно понять, и можно не вкурить - я не понимаю :).
Reply
А различие (в использовании, а не устройстве) начинается в двух случаях:
1. Update не на последнюю ревизию, вносим изменения, commit.
2. Clone, вносим изменения в оба репозитория (один, возможно, удалённый), push/pull (в случае bazaar - merge).
Кстати, насчёт shared repository - во первых, понятно, что в mercurial для многих сценариев это не надо (ветвление внутри репозитория). А во вторых - http://mercurial.selenic.com/wiki/HardlinkedClones
Reply
В силу этих отличий, рекомендованный способ работы в Bazaar немного другой.
http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-hg-users.html
Секция "Updating a local branch from upstream".
По поводу хардлинков - это интересная оптимизация, но она проигрывает shared repository тем, что работает только при локальном клонировании. Shared repository же работает _всегда_. В том числе, и при попытке вытянуть близкий бранч через сеть. И она же дает Базаару концептуальную простоту.
Reply
Reply
Если хочется совсем простоты - то можно ограничится одной концепцией - [standalone] бранч, и не использовать shared repository.
А хотим гибкости - добавляем shared repository (для чего достаточно один раз дать одну команду, вообще-то), и используем уже имеющийся навык работы с бранчами и те же самые команды - ничего в воркфлоу не меняется.
Это сложно? Я умоляю. Это куда как проще, чем работа с бранчами в hg и git.
> да ещё вылезла концепция чекаутов - без которой hg прекрасно обходится.
Без нее также прекрасно может обходится пользователь bazaar. Это требуется, если мы хотим дополнительных гарантий строгости и свежести центрального репозитория. Это дополнительная опция, которую Bazaar дать может, а hg нет. По крайней мере - простым образом - нет.
Reply
В этом случае, на сервере создается бранч для фичи, его копии создаются локально всеми разработчиками фичи. И в транк вливается бранч на сервере. Так, вообще, правильно. Нефиг лить в транк что попало.
Точно так же, при работе группы над общей фичей - не надо лить в общий групповой бранч что попало - он должен быть пригоден для тестирования. И так тоже _правильно_.
И да, неплохо, если люди будут об этом помнить.
Reply
> В этом случае, на сервере создается бранч для фичи, его копии создаются локально всеми разработчиками фичи. И в транк вливается бранч на сервере. Так, вообще, правильно. Нефиг лить в транк что попало.
Так в транк что попало и не льётся, feature-branch в него вливается по завершении.
Но мне совершенно не улыбается, создав раз структуру бранчей на сервере, руками дублировать её локально. Меня устраивает уличная магия hg - когда я просто делаю pull.
Когда мне вообще не надо думать о взаимосвязи между локальными бранчами и бранчами на сервере - ибо все бранчи есть в любом репозитории. Когда push/pull - это не действия, требующие обдумывания, а просто синхронизация.
Вот этим mercurial _проще_.
Reply
Leave a comment