Mercurial и кодовые обзоры; хороший рабочий процесс?

Question

Я в небольшой распределенной команде, использующей Mercurial для центрального хранилища. Каждый из нас клонирует его через ssh на свои собственные Linux-боксы. Наша цель - проверить работу друг друга, прежде чем отправлять изменения в центральный репозиторий, чтобы поддерживать чистоту кончика центрального узла. Что такое хороший способ поделиться кодом между разработчиками на разных боксах Linux? Я новичок в Mercurial. Варианты, которые я могу придумать (через чтение, а не опыт):

1: Автор фиксирует все локальные изменения и обновляет рабочий клон с помощью центрального совета. Автор использует пакет hg, если есть способ указать, какие локальные обороты включить в пакет. (эксперимент показал, что «пакет» захватывает только незафиксированные изменения, даже если есть предыдущие локальные коммиты, о которых центральный не знает) Автор передает пакетный файл рецензенту. Рецензент создает новый чистый клон из центрального наконечника и импортирует пакет в этот клон. или

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

3: Автор выдвигает рецензента или рецензента извлекает из автора (но как именно? Что я читаю, так это только о том, чтобы перетаскивать и извлекать данные из / в исходный обслуживаемый репозиторий и / или в один и тот же блок, а не между разными пакетами Linux .)

4: Забудьте о просмотре кода до нажатия на центральную кнопку; продолжайте и нажимайте, используя теги, чтобы определить, что было проверено или нет, и используйте Hudson (уже работающий), чтобы пометить последнюю безопасную сборку, чтобы члены команды могли знать, из какого из них извлечь.

Если ваша команда использует Mercurial и проверяет код, как вы можете заставить рецензента увидеть ваши изменения?

Answer 1

Большинство из них возможно, некоторые более утомительны, чем другие.

1. Вы можете использовать комплект, указав кончик центрального репо как --base:
   hg bundle --base 4a3b2c1d review.bundle
2. Можно просто использовать связку. Таким образом, данные набора изменений также включены.
3. Вы можете выдвинуть (и вытащить) любое хранилище, у которого есть общие предки. Если вы хотите получить от одного из своих коллег, им просто нужно запустить hg serve на своем компьютере, и вы сможете вытащить.
4. Это также работает, но вам придется поддерживать несколько голов и быть осторожным при слиянии. Если вы этого не сделаете, то может быть легко создать стабильное изменение поверх нерецензированного набора изменений, что затруднит его отмену, если позже вам потребуется исправить это не просмотренное изменение.

Из представленных вами вариантов, # 1 и # 3, вероятно, самые простые, только в зависимости от того, можете ли вы добраться до ящиков друг друга.

На заметку по теме: Этот вопрос задал мне и моему коллеге вопрос разработки Kiln , нашего (Fog Creek's) хостинга Mercurial и инструмента проверки кода. Наш план и первоначальный прототип будут содержать несколько репозиториев, один «центральный» репозиторий и кучу «обзорных» репозиториев. Процесс рецензирования может быть начат с клонирования центрального репо в репо рецензирования на сервере, а затем запускает полный репо между ними с простым веб-интерфейсом для получения и просмотра различий.

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

Answer 2

Половина ответа на этот вопрос использует ReviewBoard с Mercurial extention .Это позволяет выдвинуть определенные ревизии для просмотра, введя следующую команду

hg postreview tip

Answer 3

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

Нажмите на центральное хранилище, попросите рецензента вытащить ветку. Выполните обзор по ветке.

Когда рецензия пройдена, объедините разработку в соответствующую ветку функций.

Этот рабочий процесс, который (на мой взгляд) на удивление непопулярен, имеет много преимуществ:

1. Вся работа принимается - вам не нужно ждать, пока будет сделан обзор, прежде чем совершить.

2. Вы не создадите неправильную версию. Вы когда-либо строите только из ветви функций.

3. Текущая работа не мешает другим разработчикам.

4. В ветке разработки вы можете посмотреть последние изменения (например, наборы изменений, относящиеся к комментариям к обзору), сравнить с точкой ветвления или сравнить с последней ветвью функций - все это может дать полезную информацию.