Mercurial с несколькими проектами

Question

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

Теперь, по нескольким причинам, я хочу переключиться с SVN на mercurial с центрального сайта push.

Вопрос: Каков наилучший способ в mercurial организовать несколько проектов, которые имеют небольшой код между ними? Должен ли я создавать несколько сайтов push, по одному для каждого проекта?

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

Редактировать: Я хотел бы установить как можно больше расширений.

Edit2:

Учитывая это СВН расположение:

. 
|-- project-a 
| |-- branches 
| | |-- 1.x 
| | `-- feature-1 
| |-- tags 
| `-- trunk 
`-- project-b 
    |-- branches 
    |-- tags 
    | |-- 1.0 
    | `-- 1.1 
    `-- trunk 

(спасибо @bendin :)!)

ли лучше работать с несколькими ¯hG кнопочных репозиториев

project_a-trunk 
project_a-1.x 
project_a-feature-1 
project_b-trunk 

для филиалов. Теги складываются в соответствующую ветку.

Или вы предпочли бы пойти с двумя нажимными репозиториев в этом примере

project_a 
project_b 

с именованными ветками и, следовательно, нескольких глав в одном репо.

Преимущество, которое я вижу в репозиториях с несколькими заголовками, заключается в том, что мне не нужно искать тэг в нескольких репозиториях. Недостаток, который я вижу, заключается в том, что книга hg, похоже, препятствует множественным репозиториям. Что бы вы делали?

Answer 1

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

. 
|-- branches 
| |-- project-a-1.x 
| `-- project-a-feature-1 
|-- tags 
| |-- project-a-1.0 
| |-- project-b-1.0 
| `-- project-b-1.1 
`-- trunk 
    |-- project-a 
    `-- project-b 

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

Некоторых диверсии хранилища структурированы, чтобы сделать это, давая каждый проект своих собственного ствол, тег и филиалы:

. 
|-- project-a 
| |-- branches 
| | |-- 1.x 
| | `-- feature-1 
| |-- tags 
| `-- trunk 
`-- project-b 
    |-- branches 
    |-- tags 
    | |-- 1.0 
    | `-- 1.1 
    `-- trunk 

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

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

Answer 2

Я думаю, что вы хотите попробовать mercurial forest extension

Answer 3

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

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

Когда вы делаете выпуск, вы обычно добавляете тег в свой репозиторий Mercurial (hg tag). Вы можете свободно решить, хотите ли вы хранить репозиторий bugfix для каждой версии, если вы хотите создать их при необходимости в первый раз. Хитрость заключается в том, что

 
% hg clone -r 1.0 project-a project-a-1.0.x 

может быть использован для создания хранилища project-a-1.0.x, который имеет только историю до тега 1.0. Затем вы можете исправить ошибку в project-a-1.0.x и отодвинуть ее обратно до project-a. Дополнительные исправления могут быть сделаны в репозитории project-a-1.0.x.