mercurial ведение веток

«Как правильнее» - это вопрос почти религиозный; насколько я могу судить, более распространено использование в роли ветки отдельного репозитория. Впрочем, использование отдельного репозитория не исключает использования именованных веток.

вести все в одном каталоге переключаясь апдейтом между ветками

По-моему, это патентованно плохая практика.

ok я так и знал

именно из-за убогих веток в hg пришлось перелезть на git и дёргать hg-fast-export для синка с апстримом.

А чего именно не хватало?

А почему плохая-то?

Личноя в данный момент не вижу недостатков у модели ветвления через бранчи, подскажите?
Зато недостатки в ветвлении через копии вижу:
1. Начинаются проблемы с захардкожеными путями файлов, потому как при смене «папко-ветки» придётся их менять, либо заморачиваться с симлинками, если они есть в ОС
2. Для mercurial есть замечательный TortoiseHG Workbench, который красиво отображает граф веток и позволяет мержить их в пару кликов.
3. Вся сложность хода разработки прячется вместе с историей внутри репозитория mercurial, в один момент времени ты видишь две вещи: текущую ревизию и граф дерева ревизий вместе с брачами, их авторами и комментариями; а не кучу папок с непонятными названиями, непонятной историей, непонятно кем и когда созданных.

Личноя в данный момент не вижу недостатков у модели ветвления через бранчи, подскажите?

Там же ясно сказано: плоха идея работать с несколькими бранчами _в одном каталоге_.

недостатки в ветвлении через копии вижу:
1. Начинаются проблемы с захардкожеными путями файлов

Wut? Ты моделью бранчинга обходишь кривизну кода?

Для mercurial есть замечательный TortoiseHG Workbench,

Нерелевантно.

в один момент времени ты видишь две вещи: текущую ревизию и граф дерева ревизий вместе с брачами, их авторами и комментариями; а не кучу папок с непонятными названиями, непонятной историей, непонятно кем и когда созданных

Wut? Какие папки (каталоги, наверное?), откуда «куча» (после мержа в основное дерево каталог удаляется), откуда «непонятная история»? Что за страшилки, в самом-то деле.

А чего именно не хватало?

Как всегда - ума.

Чем плохо всю разработку со всеми ветками держать в одном репозитории?

То что в гите называется ветками в хг называют букмарками и оно один в один отображается на гитовую идеологию.

Чем плохо всю разработку со всеми ветками держать в одном репозитории?

Эх. Где я сказал, что это плохо? Я считаю, что попеременно работать с несколькими ветками в одном рабочем каталоге - плохо.

Да, и о каких ветках идет речь - именованных, неименованных, букмарках?

UPD. впрочем, я не уверен, что держать в основном репозитории незаконченные бранчи - это хорошо (когда в репозитории несколько десятков голов, как в PyPy, это как минимум раздражает).

А что можно называть попеременной работой? Переключаться в другую ветку до закрытия предыдущей? Чем плохо?

Для определенности пусть будут именованные ветки.

ИМХО

все в одном каталоге

хотя для огромных проектов может и не так.

Переключаться в другую ветку до закрытия предыдущей? Чем плохо?

Тем, что придется делать make clean && ./configure (а если не сделаешь, можешь наловить всяких странных багов).

И еще непонятно - а зачем так делать, в чем профит?

Для определенности пусть будут именованные ветки.

Я считаю, что именованные ветки нужно использовать тогда, когда ветка живет хотя бы несколько недель.

То что в гите называется ветками в хг называют букмарками и оно один в один отображается на гитовую идеологию.

Hg Bookmarks Made Me Sad

По-моему, это патентованно плохая практика.

возможно это ещё и от проекта зависит

Я в таких случаях всегда вспоминаю фразу «sharing a working copy leads to the confusion, just like sharing a desk does».

Тем, что придется делать make clean && ./configure (а если не сделаешь, можешь наловить всяких странных багов).

Если проект их использует.

Если подмена файла проекта не вызывает проблем, то это удобно тем, что не нужно перезапускать IDE для открытия разных веток проекта. Но проблемы начнутся тогда, когда нужно иметь под рукой сразу несколько веток.

Полагаю, что как и везде, все минусы и плюсы определяются деталями, и все варианты имеют право на жизнь.

Тем, что придется делать make clean && ./configure (а если не сделаешь, можешь наловить всяких странных багов).

Если проект их использует.

А есть проекты, которые не используют разновидность make (cmake, ant, maven)?

не нужно перезапускать IDE для открытия разных веток проекта

Не знаю про другие IDE, но в Eclipse можно без проблем держать открытыми несколько проектов.

IAR, не использует указанные разновидности, и с несколько проектов только через несколько запущенных экземпляров.

По крайней мере в вебдеве мы создаём отдельную ветку для каждой новой задачи, а иногда и для каждого отдельного бага. Конпелять то ничего не нужно :)

А есть проекты, которые не используют разновидность make (cmake, ant, maven)?

ну а кроме «компилируемого» девелопа ничего нет, само собой :) :)

По крайней мере в вебдеве мы создаём отдельную ветку для каждой новой задачи

Формально говоря, в DVCS для новой задачи всегда создается новая ветка. Этого тупо невозможно избежать.

ну а кроме «компилируемого» девелопа ничего нет, само собой :) :)

Я говорю о том, с чем знаком. А если ты думаешь, что в «некомпилируемом девелопе» ты не встретишь этих проблем - думай дальше.

А если ты думаешь, что в «некомпилируемом девелопе» ты не встретишь этих проблем - думай дальше.

да ладно, чего так сурово, я с гитом не вствечал проблем на которые ты намекаешь, а если что-то и вылазит - ну так это легко решаемо

Тут пишут:

Современный взгляд на CI, изложенный например в книге «Continuous Delivery», исходит из того, что любая branch — это зло. В идеале разработка должна вестись в единственной ветке trunk. Следует избегать создания любой новой ветки разработки настолько, насколько это возможно.

У вас CI?

Формально говоря, в DVCS для новой задачи всегда создается новая ветка. Этого тупо невозможно избежать.

Оттужа же:

Особенно вредны так называемые «feature branches», ветки, единственное предназначение которых — отложить трудности интеграции новых feature до последнего момента, что полностью противоречит приципу Continuous Integration («непрерывной интеграции»).

Причем здесь это?