Mercurial репозитории со многими активными разработчиками?

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

Поэтому мне интересно, есть ли рабочий процесс, который мы здесь не рассматриваем?

Я говорю о том, что я провел небольшой автоматический тест. Мы - 14 человек, которые работают над одним проектом, разделенным на 4 команды. Чтобы смоделировать 14 (я выбрал 10, округленное число) людей, работающих параллельно над кодом, используя Mercurial DVCS, отправляя его в тот же центральный главный репозиторий, я написал скрипт.

Я создал новый "главный" репозиторий, а затем клонировал его для 10 виртуальных людей
Затем я запустил итерационный цикл 1000, выбрав случайный клон и выполнив одно из следующих действий:
- В 10% случаев выполняйте извлечение из мастера, объединяйте, фиксируйте объединение и нажимайте
- В 90% случаев вносите локальные изменения и фиксируйте

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

Это имитирует людей, работающих локально, выполняя коммиты 1+ перед вытягиванием, объединением и толканием (чтобы избежать голов 2+ в главном репо). Возможно, этот рабочий процесс неправильный.

Вот пример того, как теперь выглядит хранилище (скриншот + ссылка на репо):

~~Репозиторий можно найти здесь: http://hg.vkarlsen.no/hgweb.cgi/parallel_test/graph.~~ К сожалению, этот репозиторий больше недоступен, и у меня больше нет копии кода из-за неудачного резервного копирования, но это был просто пример для посещения, это не должно быть больше важно

Это выглядит ужасно грязно, и, как я уже сказал, я не могу найти ни одного хранилища с похожей историей. Под "грязным" я подразумеваю, что похоже, что более старая история проекта почти всегда будет иметь 10 параллельных ветвей. Близко к вершине, это, конечно, сужается, но будет расширяться по мере того, как люди, которые в настоящее время работают в своем локальном хранилище, подталкивают к мастеру.

Итак, у меня есть два вопроса:

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

Ответ 1

Впечатляющая подготовка!

Это всегда выглядит грязно, если вы немного вернетесь назад и посмотрите на все старые коммиты одновременно. Это всегда сужается, даже если смотреть на немного старую историю. См. http://hg.intevation.org/mercurial/crew/graph/12402?revcount=120, например. Это не самый последний коммит, но показывает всю историю до этого коммита.
Rebase очень помогает, особенно если люди работают в разных областях. (Я обычно проверяю входящие коммиты, чтобы увидеть, не существует ли потенциальных конфликтов файлов или функций, и если нет, я делаю ребаз.)

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

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

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

Ответ 2

У меня 12 разработчиков, работающих в одном и том же хранилище Mercurial на работе, и наша история выглядит не так. Иногда возникают слияния, но большинство слияний связано с объединением фактических ветвей, т.е. В нашей основной ветке разработки может произойти слияние с выпуском исправления, выпущенным в ветки производства/выпуска.

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

Если ничто не было совершено, так как они начали совершать толкание, без проблем.

Если кто-то еще совершил какое-либо изменение, Mercurial жалуется, что нажатие создаст удаленные головки. Затем разработчик выполняет hg pull --rebase и повторяет попытку. Толчок проходит, и все счастливы.

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