Как мы управляем гранулярными изменениями в центральном / общем хранилище?

Question

Я годами использовал Mercurial локально, но сейчас мы проводим пилотный переход от Subversion в моей компании.

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

Мой вопрос: как мы можем справиться с тем фактом, что, поскольку наборы изменений являются более детальными, это позволяет разработчикам обновить версию, которая не собирается? Мы пришли из мира, где вы можете оформить покупку в любом месте репозитория и ожидать, что сможете сделать релиз с этого момента. С DVCS, как узнать, где находится «безопасная» ревизия?

Эта проблема несколько решена в этом вопросе , но мне больше интересно узнать, как с этим справиться, используя репозитории (а не именованные ветки).

Я понимаю, что есть способы изменить историю (например, расширение свертывания ), чтобы изменения сворачивались в истории хранилища, но мы хотели бы сохранить историю.

Глядя на деревья mercurial и mozilla , я не вижу четкого способа определить, где безопасные ревизии должны синхронизироваться. Разве это не так важно, как мы думаем?

Answer 1

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

Answer 2

Политическим решением может быть «не вставляйте дерьмо в основной репо», не так ли?

Техническим решением будет не тег , а одна закладка ("KnownAsGood"), применяется к последнему работающему HEAD ветви по умолчанию и соглашению между разработчиками: "Обновлять не до чаевых, а до закладки"

Кто будет проверять коммиты и перемещать закладки - другой вопрос из проектауправление "тегом

Answer 3

Вам действительно нужно проверить ЛЮБУЮ старую ревизию и ожидать ее сборки?

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

По поводу старых редакций:

• если вы хотите снова собрать более старые официальные выпуски вашего программного обеспечения (например, вы сейчас находитесь на версии 1.6 и хотите сделать исполняемый файл v1.2), вы можете ожидать, что тег 1.2 также будет собираться, если все всегда придерживался политики «не выдвигай незаконченную работу».
• если вы хотите взять ЛЮБУЮ ревизию и собрать ее ... ну, вам это действительно нужно? Любые ошибки в предыдущих версиях, вероятно, будут относиться к официальным релизам (см. Выше материал «1.2 tag»), а не к чему-то промежуточному.
• если вам действительно нужна сборочная версия в промежутке между официальными выпусками (по какой-либо причине), вам придется просмотреть сообщения коммита и найти коммит, который говорит feature 'foo' finished (а не тот, который говорит started implementation of feature 'foo').
  Да, это требует немного размышлений / здравого смысла, но я не могу себе представить, что вам это понадобится очень часто.

Answer 4

Вы всегда можете пометить ваши коммиты.Это могут быть основные / второстепенные версии, успешные сборки или как вам угодно.В их репозиториях вы можете увидеть теги mercurial и mozilla .