Использование локальных клонов Mercurial для разветвленной разработки?

Question

Я бывший пользователь SVN, пытающийся найти лучший способ сделать разветвленную разработку в hg.Мой проект довольно новый, на данный момент не имеет филиалов.Мой друг предложил сделать местный клон репо.тогда работать в этом было бы лучше, чем использовать именованную ветвь.

Так что, если я использую эту модель, рабочий процесс будет:

• [скажем, оригинальный проект был клонирован, чтобы быть в c: \ projects \ sk \ tracker]
• hg клон https: [url of repos] tracker_featurex [будет выпущено из c: \ projects \ sk]
• изменить на subdir tracker_featurex
• регистрируйся и нажимай как обычно
• [опционально, как мне вытащить изменения из основных репо.в этот?]
• [последний шаг, как я могу получить изменения от этого клона обратно в основной ствол?]

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

Большое спасибо всем, кто может помочь, Фред

Answer 1

Я бы порекомендовал вам взглянуть на пост Стива Лоша о ветвлении в Mercurial: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

Он просматривает различные типы веток (клоны, закладки, именованные ветви, анонимные ветви), а также команды, которые вы запускаете для каждой из них. У каждого из них есть свои плюсы и минусы. Локальные клоны хороши, если вы являетесь единственным разработчиком, но они не так полезны в рабочем процессе, когда над веткой нужно работать более чем одному разработчику. Утверждение, что клоны повсеместно лучше названных ветвей, - миф. Вы должны найти модель ветвления, которая соответствует вашему рабочему процессу.

Обновление:

Если вы хотите сделать локальные клоны, вы можете переместить свои изменения, используя hg push из нового рабочего пространства (при условии, что у вас есть папка Projects и репозиторий с именем test):

Projects> hg clone test test-new-feature
Projects> cd test-new-feature
Projects/test-new-feature> <do some work>
Projects/test-new-feature> hg commit -m "Work is done."
Projects/test> <Might need a pull/merge here>
Projects/test-new-feature> hg push

Если в репо test есть изменения, вам нужно вытащить / объединить их, прежде чем нажимать.

Вы также можете hg pull из исходного рабочего пространства:

Projects> hg clone test test-new-feature
Projects> cd test-new-feature
Projects/test-new-feature> <do some work>
Projects/test-new-feature> hg commit -m "Work is done."
Projects/test-new-feature> cd ../test
Projects/test> hg pull ../test-new-feature

Это может создать несколько голов в репо test, и вам потребуется слить / зафиксировать.

Projects/test> hg merge
Projects/test> hg commit -m "Merged in new-feature."

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

Answer 2

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

Чрезмерно общее и амбициозное утверждение. Когда вы клонируете за функцию, у вас есть только одна ветвь ( с именем ветвь) на репо, но не более (практически, кратко).

Когда функция завершена, вам нужно «нажать на родителя» | «извлечь из клона», чтобы вернуть изменения обратно. На этом этапе, если некоторая работа была сделана в родительском репо после клона, появится анонимная ветвь (+1 голова), и слияние является обязательным (так же, как для работы с именованным brach в одном репо), но, он назвал brach, может сказать что-то fast позже (вы используете хорошие имена, не так ли?), анонимная ветка почти ничего не говорит без дополнительных уловок (закладки, fe). Часть моего репо, приведенная ниже, как пример работы в клоне с промежуточными пуллами и обязательными слияниями после пуллов / (извините, русские коммит-сообщения) и , даже сейчас я не могу вспомнить , почему я клонировал репо для передовые статьи - возможно, я просто играю с Clones-Workflow

Answer 3

Я переворачиваюсь на Hg, поэтому примите то, что я говорю, с осторожностью: -)

Я люблю назвав ветви, но используйте их очень разумно!Подход, который я использую ниже, имеет свои недостатки, но он хорошо работает в моей нынешней среде - небольшом магазине.Я не возражаю против сохранения истории навсегда, и я не обеспокоен уменьшением количества коммитов (но Mq / record / etc может решить этот последний бит).

Так я использую ветки в коде, который яработа на:

1. ветка по умолчанию.
   • Он построен на сервере сборки.
   • У него должен быть только один заголовок.
   • Это всегда должно компилироваться.
   • Это всегда должно быть "Наилучшие усилия »при заполнении ошибок / функций.
2. Ветка" Workbench ".
   • Может иметь несколько голов.
   • Приветствуются анонимные ветки .Общие закладки используются для «именования» активных анонимных веток.
   • Состояние должно быть почти всегда компилируемым, но это не является обязательным требованием.
   • Представляет «работа в процессе».

Хорошо, вот как мой процесс может выглядеть следующим образом: (я исключил шаги pull / push / merge-их).

1. Я получаюсообщение об ошибке в.
2. Я переключаюсь на подсказку "workbench" (или любую другую ревизию).
3. Я исправляю ошибку, возможно фиксируя несколько раз.(Я действительно должен научиться использовать очереди или записи и т. Д.)
4. (Если я прерван в вышеуказанном процессе, например, должен работать над другой ошибкой, или в противном случае отвлекся, я создам новыйПоднимитесь выше, где # 2, или в зависимости от обстоятельств. Я могу дать текущей анонимной ветви подсказку имени с закладкой, или я не могу.)
5. После завершения я объединяю соответствующую ветку/ меняется на "default", и, надеюсь, сервер сборки все еще любит меня: -)

Я думаю, что лучше всего сделать забыть о том, как работали ветки в SVN .Они вообще не любят именованные ветки, и любой, кто говорит иначе, зацикливается на том, что у них обоих есть «имена», и не намного. Каждая ветвь в Hg является частью «именованной ветви» (то есть с именем, связанным с ним, будь то «по умолчанию» или «верстак» или иным образом).Но это не имеет значения, за исключением организации: ветвь - это ветвь , и не имеет значения, относится ли она к «наконечнику» анонимной ветки или к вершинеединственная голова (на самом деле анонимная ветвь сама) в именованной ветке .

Попробуйте несколько вещей, используйте то, что лучше всего работает:)