Установка Mercurial: один центральный репо или несколько?

Question

Моя компания переходит с Subversion на Mercurial. Мы используем .NET для нашего продукта. У нас есть решение с примерно дюжиной проектов, которые представляют собой отдельные модули, не зависящие друг от друга. Мы используем центральное репо на сервере с push / pull для нашей интеграционной сборки.

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

Я очень новичок в hg и DVCS, поэтому некоторые рекомендации очень ценятся.

ETA: На hginit.com Джоэл говорит:

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

Было бы замечательно, если бы кто-то мог расширить это или указать мне больше документации.

Answer 1

Здесь следует принять во внимание тот факт, что Mercurial не поддерживает извлечение каталогов, как это делает Subversion. Одна из типичных настроек Subversion состоит в том, чтобы иметь одно гигантское хранилище с несколькими отдельными проектами, и когда кому-то понадобится код, он просто извлекает подкаталог, содержащий этот проект. Вы не можете сделать это в Mercurial. Вы либо берете весь репо, либо ничего. Если всем, кто работает над этими проектами, не нужен весь код, все время вам может потребоваться разбить его на отдельные репозитории.

РЕДАКТИРОВАТЬ: Эта ссылка может быть полезна при настройке, в частности, в разделе «Публикация нескольких репозиториев».

Answer 2

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

Answer 3

Из моего опыта , а не на основе исследований и т. Д., Я бы сказал, что каждый логический BLOB-объект является хранилищем. Если вы делитесь кодом между подпроектами, они должны находиться в одном репо. будет полной функциональностью subrepo, но в настоящее время (апрель 2010 г.) она не полностью реализована.

Answer 4

Я довольно плохо знаком с Mercurial (моя компания делает скачок от SourceSafe), поэтому я не знаю, что скажет еще опыт.

Для меня имеет смысл иметь один репозиторий на решение Visual Studio. Если ваши модули действительно не зависят друг от друга, почему они все в одном решении? Если у вас есть веская причина для того, чтобы все они находились в одном решении, то, вероятно, это причина держать их в одном хранилище. Если у них нет веских причин для того, чтобы они находились в одном решении, то для меня больше смысла в хранилище и решении для каждого.

Редактировать: Итак, поскольку все модули собраны вместе и должны быть интегрированы, это подтолкнет меня к одному решению и одному репозиторию.

Mercurial отлично справляется со слиянием, но у меня возникли проблемы с файлом решения при объединении нескольких проектов одновременно. Это путается с несколькими End Project строками. Поэтому, если вы не добавляете новые проекты очень часто, ваши слияния должны быть плавными.