Mercurial Best Practices - Раздел по функциям / задачам?

Question

Я только что перешел на Mercurial из SVN.Я сделал некоторые базовые вещи (импортировал мой код, сделал коммиты, изучил log / commit / revert / etc.) И прочитал несколько уроков по ветвлению / слиянию.

Мой вопрос сейчас: Каков наилучший ("Mercurial") способ использования Mercurial? " Я не хочу следовать парадигмам SVN; я хочу делать вещи" правильным "способом.

Я должен упомянуть, что яЯ являюсь единственным разработчиком в большинстве моих проектов, и я использую методы Agile / Scrum. Может быть, мой вопрос действительно должен быть Должен ли я клонировать / разветвляться для каждой функции? Для задачи? Я помню, что читал, что этодолжно быть в случае с Git, и это позволяет вам по существу поддерживать одновременную работу нескольких копий и разделять функции, исправления ошибок и прочее (т.е. хранить рабочую копию отдельно для каждой другой вещи, которую вы делаете).И это, по-видимому, также является частью лучших практик Mercurial .

Или я мог бы просто сохранить одну копию, внести свои изменения и выполнить многократную фиксацию. Что угодно.

Если эта очередьЭто слишком субъективно, я не против закрыть его, при условии, что кто-то может связать меня с некоторыми материалами для чтения на , как , чтобы лучше всего использовать Mercurial.Вот чего я хочу.

Answer 1

Говоря как (в основном) сольный разработчик, я думаю, что мой ответ ... да. Когда я знаю, что я делаю быстрые изменения, я делаю это в своем «основном» каталоге разработки, но если у меня есть какие-либо сомнения относительно того, насколько длинным или сложным будет что-то, я делаю ветку в самом начале. Приятно то, что вы действительно можете сделать это любым способом (и в любом порядке), который работает для вас. Если вы работаете в своем основном каталоге разработчиков над длинным модом, и кто-то входит и нуждается в быстром исправлении сейчас, просто клонируйте ствол, исправьте его, проверьте его, и Боб станет вашим дядей!

Я оглядываюсь на свои дни с SCCS / RCS / CVS с грустью.

Я собираюсь привести 3 дизайнеров в Землю Обетованную. Они старой школы и уже давно используют Dreamweaver в общих каталогах (ужас!). В эти выходные мы переносим их в мир XAMPP, TortiseHG, rsync и deve / staging / production.

Обновление: Я сформулировал свой ответ весьма двусмысленным образом. Спасибо, что позвонили мне, Майкл Э.

Мой "основной каталог разработки" на самом деле является клоном production-master. Когда я говорю «ветвь», я имею в виду, что я собираюсь работать над чем-то некоторое время, часто от нескольких дней до месяца или более, но это все еще клон «чего-то». Я знаю, что это звучит расплывчато, но иногда я работаю с другими разработчиками, и мы передаем материал взад и вперед, и мы просто не слишком беспокоимся о слиянии с транком, пока не пришло время перейти к постановке. (И даже тогда это часто довольно безболезненно.)

Таким образом, «быстрое исправление» для меня означает обновление моего «основного» dev-каталога на транк, хакерство, тестирование, переход на промежуточную работу на основной машине (и тестирование), а затем переход к производству (и тестированию). В большинстве случаев быстрые исправления выполняются как анонимная ветвь.

Кстати, клонирование против локального хранилища происходит так быстро, что нет причин (по моему мнению) делать что-либо еще. У меня есть один средний проект с более чем 7000 файлов и около 4 лет ежедневных коммитов от 4 разработчиков - репозиторий составляет около 200 МБ. Время клонирования (на старомодной машине в моем гараже) составляет 10 секунд. Я держу локальный клон мастера удаленного производства и делаю почасовые выборки с помощью cron. НТН.

Answer 2

Базовое руководство: https://www.mercurial -scm.org / гид /

Руководство по ветвлению: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

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

Answer 3

Перейдите по этой ссылке.http://hginit.com/

Джоэл Спольски четко объясняет разницу между унаследованными централизованными VCS и DVCS.

Он также проведет вас через шаги, чтобы познакомиться с рабочим процессом ртути, происходящим из подрывной деятельности.

Answer 4

Я обнаружил, что именованные ветви предпочтительнее клонирования для пары случаев.Если настройки проекта не проверены в управлении исходным кодом, для их клонирования необходимо скопировать эти параметры во все мои клоны.Большая часть моей работы находится в Django, где наличие local_settings.py не в контроле исходного кода является обычной идиомой.Также я считаю, что делиться клонами не так просто, как делиться именованными ветками.Если я единственный разработчик, работающий над функцией, то клонирование - это хорошо.Во-вторых, мне нужно, чтобы кто-то помог мне с функцией именованной ветви, был бы лучшим выбором.

@ k3b упомянул gitflow, и в разработке есть плагин hg, который делает то же самое в hg, который использует именованные ветви,https://bitbucket.org/yinwm/hgflow/wiki/Home

Answer 5

Нет .Вместо ветви я бы клонировал рабочий каталог / репозиторий для функциональной ветви.

Я следую за исключительным истощением в a-success-git-branching-model .

Обратите внимание, что упомянутая статья предназначена для git, а не для hg.Однако модель ветвления универсальна, только синтаксис между git и hg отличается.

[обновление 2013-01-31] ​​Спасибо @Alex за ваш комментарий.я не знал о различиях между hg и git .Есть ли кто-нибудь с опытом работы с hg, который может проверить, применима ли модель git ветвления к hg или нуждается в модификациях для работы с hg (кроме синтаксиса командной строки)?