В защиту Bazaar
Сегодня прочел в сети о том, что Bazaar говно. :)
В сети должно быть равновесие. :) Поэтому, из соображений благодарности к его авторам, я расскажу о том, что Bazaar - лучшая DVCS для человека, который хочет использовать все плюсы DVCS, и одновременно не забивать себе голову ненужной хуйней ерундой. Я весной 2010 года выбирал между хорошо знакомым ( Read more... )
В сети должно быть равновесие. :) Поэтому, из соображений благодарности к его авторам, я расскажу о том, что Bazaar - лучшая DVCS для человека, который хочет использовать все плюсы DVCS, и одновременно не забивать себе голову ненужной хуйней ерундой. Я весной 2010 года выбирал между хорошо знакомым ( Read more... )
Хотя я и концептуальной не вижу: вместо одной сущности (репозиторий с деревом ревизий) имеем две - бранч и репозиторий, да ещё вылезла концепция чекаутов - без которой hg прекрасно обходится.
О простоте: типичный сценарий - trunk + feature-branch. Допустим, работаю я на двух машинах (или эту фичу делают два разработчика), ну и есть центральный репозиторий (просто для удобства синхронизации).
Соответственно, в hg - центральный репозиторий с двумя named-branch (default и feature-branch).
В bazaar, судя по тому тексту, центральный репозиторий с двумя бранчами (trunk и feature-branch), и на каждой рабочей машине по три бранча - trunk, feature-branch (куда делается pull с сервера) и рабочая копия feature-branch. Все три надо создать руками и помнить, что с чем синхронизировать.
Ничего страшного в общем-то, просто hg для меня проще и прозрачнее - не надо делать руками то, что может сделать машина (хотя для другого сценария это будет недостатком - например, если мне понадобится из моей ветки default вливать в ветку feature-branch центрального репозитория).
Как обычно: больше свободы - больше работы руками.
Кстати, как в bzr посмотреть дерево ревизий? (ну, когда feature-branch ответвился от trunk, когда в него вливали изменения из trunk, когда его влили обратно в trunk)
Reply
Если хочется совсем простоты - то можно ограничится одной концепцией - [standalone] бранч, и не использовать shared repository.
А хотим гибкости - добавляем shared repository (для чего достаточно один раз дать одну команду, вообще-то), и используем уже имеющийся навык работы с бранчами и те же самые команды - ничего в воркфлоу не меняется.
Это сложно? Я умоляю. Это куда как проще, чем работа с бранчами в hg и git.
> да ещё вылезла концепция чекаутов - без которой hg прекрасно обходится.
Без нее также прекрасно может обходится пользователь bazaar. Это требуется, если мы хотим дополнительных гарантий строгости и свежести центрального репозитория. Это дополнительная опция, которую Bazaar дать может, а hg нет. По крайней мере - простым образом - нет.
Reply
В этом случае, на сервере создается бранч для фичи, его копии создаются локально всеми разработчиками фичи. И в транк вливается бранч на сервере. Так, вообще, правильно. Нефиг лить в транк что попало.
Точно так же, при работе группы над общей фичей - не надо лить в общий групповой бранч что попало - он должен быть пригоден для тестирования. И так тоже _правильно_.
И да, неплохо, если люди будут об этом помнить.
Reply
> В этом случае, на сервере создается бранч для фичи, его копии создаются локально всеми разработчиками фичи. И в транк вливается бранч на сервере. Так, вообще, правильно. Нефиг лить в транк что попало.
Так в транк что попало и не льётся, feature-branch в него вливается по завершении.
Но мне совершенно не улыбается, создав раз структуру бранчей на сервере, руками дублировать её локально. Меня устраивает уличная магия hg - когда я просто делаю pull.
Когда мне вообще не надо думать о взаимосвязи между локальными бранчами и бранчами на сервере - ибо все бранчи есть в любом репозитории. Когда push/pull - это не действия, требующие обдумывания, а просто синхронизация.
Вот этим mercurial _проще_.
Reply
Создается не "структура", а feature branch под задачу.
На сервере - создаем бранч для рабочей группы:
bzr branch trunk my_feature_group
На клиенте, члены рабочей группы говорят:
mkdir my_feature_group
cd my_feature_group
bzr branch sftp://bla-bla-bla/my_feature_group trunk
Именно так - правильно. Ибо другим людям, кто не работает над фичей, совершенно не обязательно иметь у себя этот бранч.
Теперь, перед тем, как поменять что-либо, член рабочей группы делает:
bzr branch trunk i_wanna_do_this
И меняет там, делая столько коммитов, сколько захочет, и другим членам группы совсем не обязательно это видеть, пока изменение не готово.
А вот когда готово - он вливает это в trunk, и публикует. Причем, если trunk будет bound бранчем - все будет ваще зашибись.
В чем проблема? Где необходимость "воссоздавать структуру"? Все просто, понятно, и логично, нет?
Reply
Я во время всей процедуры оперирую одним понятием - бранч. И одним единственным, однородным набором операцией. А вы будете оперировать понятиями бранч и репозиторий, и применять _разные_ операции.
Это и есть следствие концептуальной простоты. В Bazaar проще, прозрачнее, и понятнее.
Reply
Reply
Я ему дам адрес нужного бранча, и три понятных ему команды с понятными названиями - чекаут, мерж, и коммит. И ни у меня, ни у него не будет никаких проблем, и нам обоим будет удобнее. Ему даже мануал читать не придется.
А вот куда в данной ситуации пропадет простота и удобство меркуриала? :)
Reply
Кстати, раз уж рассматриваем случай неграмотного разработчика - то стоит рассмотреть и разработчика вообще без опыта использования vcs (пришёл студент). Что проще?
Reply
И естсественно он проще для человека, не знакомого с VCS вообще.
Reply
Я наблюдаю обратное - что у меркуриала модель изумительно проста и что он проще для освоения. Так что, если не считать друг друга идиотами - можно прийти к выводу, что это всё вкусовщина.
Reply
Во-вторых, в отличии от "автора статьи", я рассказываю не о том, что Х - говно, hate, and hate.
И в третьих, к выводу что это "вкусовщина", прийти нельзя, ибо различия объективны и весьма существенны. И эти различия к вашим или моим предпочтениям отношения не имеют - они есть незвисимо от предпочтений, и проявляются в разных ситуациях.
А вот от употребления слова "идиот" я вас бы предостерег. Идиотов я, видите-ли, в комментах не терплю, и сразу баню.
Reply
Reply
Leave a comment