Mercurial и разные конфиги в бранчах dev/test/prod

Кстати, cast alozovskoy (дал совет в схожей теме: Управление конфигами + Ansible ).

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

Как минимум ты тогда запиливая новую фичу сразу поменять конфиг для продакшна под ее требования. Не рискуя продолбать это при мерже.

и это универсальный ответ (паттерн) для кейса «много»: серверов, конфигов, етц.

Я не совсем вопрос понял, увы не знаю что ответить. Если выбор хранить ли конфиги вместе с кодом или нет то я плясал бы от зоны ответственности (то есть может ли кодер править конфиги СУБД или нет) и связанности компонентов. Если вопрос про ветки, то я бы (в идеале, IRL так у меня не получается ввиду особенностей сред) коммитил бы конфиг в dev-ветку, накатывал@тестил, мержил бы в test, накатывал и тестировал, мержил бы в прод (master) и катил на продуктив. В случае специфичных параметров среды (таких как адрес сервера БД и подобное) кофиг представлял бы собой шаблон, который парсила бы система управления конфигами при раскидывании конфигов на нужные стенды.

Если вопрос о том, хранить ли конфиги в vcs (с привязанной к ней scm) то тут однозначно да, это экономит кучу времени и нервов (пробовал оба варианта).

// С Mercurial не работал, представленная концепция подходит под git\svn, но думаю в случае hd разница не будет большой.

Благодарю за развёрнутый ответ!