Mercurial и обзоры кода ; хороший рабочий процесс?
Я нахожусь в небольшой распределенной команде, использующей Mercurial в качестве центрального репозитория. Каждый из нас клонирует его через ssh на свои собственные Linux-серверы. Наше намерение состоит в том, чтобы проанализировать работу друг друга, прежде чем отправлять изменения в центральный репозиторий, чтобы поддерживать чистоту информации из центрального хранилища. Как лучше всего делиться кодом между разработчиками на разных Linux-компьютерах? Я новичок в Mercurial. Варианты, которые я могу придумать (через чтение, а не на опыте):
1: Автор фиксирует все локальные изменения и обновляет рабочий клон с помощью подсказки из центра. Автор использует пакет hg, если есть способ указать, какие локальные версии включать в пакет.(эксперимент показал, что «пакет» захватывает только незавершенные изменения, даже если есть предыдущие локальные коммиты, о которых не знает центр) Автор получает файл пакета рецензенту. Reviewer создает новый чистый клон из центральной части и импортирует пакет в этот клон. или,
2: После того, как и автор, и рецензент извлекут из центрального совета, автор использует патч, а рецензент импортирует патч. или,
3: Автор отправляет рецензенту или рецензент извлекает от автора (но как именно? Я прочитал только о отправке и извлечении в / из исходного обслуживаемого репозитория и / или в том же box, а не между разными Linux-модулями.)
4: Забудьте просматривать код перед тем, как перейти в центральный; продолжайте и нажимайте, используя теги, чтобы определить, что было проверено или нет, и используйте Hudson (уже работающий), чтобы пометить последнюю безопасную сборку, чтобы члены команды могли знать, из какой из них брать.
Если ваша команда использует Mercurial и выполняет рецензирование кода, как сделать так, чтобы рецензент увидел ваши изменения?
1 ответ
Большинство из них возможны, некоторые более утомительны, чем другие.
- Вы можете использовать пакет, указав в конце центрального репозитория
--base:
hg bundle --base 4a3b2c1d review.bundle - Можно просто использовать пакет. Таким образом, данные набора изменений также включены.
- Вы можете отправлять (и извлекать) в (из) любой репозиторий, который имеет общего предка (предков). Если вы хотите получить данные от одного из своих коллег, ему просто нужно запустить
hg serveна своей машине, и вы сможете получать запросы. - Это тоже работает, но вам придется поддерживать несколько головок и быть осторожным при слиянии. Если вы этого не сделаете, может быть легко создать стабильное изменение поверх непроверенного набора изменений, что затруднит отмену, если вам понадобится исправить этот непроверенный набор изменений позже.
Из представленных вами вариантов, №1 и №3, вероятно, самые простые, просто в зависимости от того, сможете ли вы добраться до ящиков друг друга.
Кстати, это вопрос, который задал мне и моему коллеге разработку Kiln, нашего (Fog Creek) хостинга Mercurial и инструмента проверки кода. Наш план и первоначальный прототип предусматривали наличие нескольких репозиториев, одного «центрального» репозитория и нескольких репозиториев «обзоров». Процесс проверки начинался с клонирования центрального репозитория в репозиторий обзора на сервере, а затем запуска полного репозитория различий между ними с помощью простого веб-интерфейса для получения и просмотра различий.
Мы значительно усовершенствовали этот рабочий процесс, но общая идея, состоящая в том, чтобы иметь репозиторий ветки, в который можно отправлять непроверенные изменения, и интерфейс для их просмотра перед тем, как отправить их в центральный репозиторий, осталась прежней. Я не хочу рекламировать здесь, но я рекомендую попробовать.