Рекомендуемый Подвижный репозиторий/структура папок для пользователя SVN

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

Project1
  trunk
  branches
    1.0
    1.1
Project2
  trunk

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

Как я должен воспроизвести это с Hg? Для приправления этого немного, я люблю идею 'стабильных', 'быстродействующих' и 'dev' репозиториев/папок и хотел бы представить это, если это возможно.

Я - новичок Hg так любая справка, или совет приветствуется.

24

svn mercurial

задан Rob 2 March 2010 в 22:44

3 ответа

Но прежде чем вы это сделаете - проверьте это: hginit.com - это полчаса чтения, и в нем есть раздел для svn-пользователи.

Я стал намного мудрее, и я решил отказаться от структуры / trunk / tag и использовать mercurial по-другому. Теперь у меня есть репозиторий для каждого проекта, который просто содержит структуру проекта, и я помечаю его с помощью команды mercurial tag.

. Джеспер Хауге

19

ответ дан 28 November 2019 в 23:01

Mercurial действительно хорошо документирован. Вам нужно только знать, где искать в Wiki.

Вы можете посмотреть вики-статью Mercurial RepositoryNaming , чтобы найти некоторые из своих ответов.

Вам также следует прочитать официальное руководство Mercurial: Mercurial: The Definitive Guide

Удачи!

9

ответ дан 28 November 2019 в 23:01

Другие вопросы по тегам:

svn mercurial

Похожие вопросы:

score 26 · Accepted Answer

Есть несколько структурных различий между репозиториями Subversion (SVN) и Mercurial (HG), или, для краткости, репо, которые подразумевают, как вы «спроектируете» свою иерархию:

Mercurial лучше работает с одним проектом на репозиторий : поскольку вам всегда нужно клонировать весь репозиторий, наличие нескольких проектов в одном репозитории может иметь большое влияние на время клонирования, а также на операции выталкивания / вытягивания, поскольку вам придется синхронизировать все задания, которые каждый раз выполнялся над другими проектами, кроме вашего.
SVN не имеет «сильного» понятия тегирования / ветвления, в то время как Mercurial имеет : в SVN (на момент написания) каждая ветвь, каждый тег, по сути, является копией данного проекта / папки. /что бы ни. Рекомендуемая структура ствола / ветвей / тегов поможет вам найти свои «копии» обратно, не более того. С другой стороны, в mercurial четко определены ветви и теги. Тег - это на самом деле имя, которое вы присваиваете определенной ревизии, и вы можете запросить все существующие теги. Что касается ветвей, вы увидите, что существует МНОЖЕСТВО способов их обработки, но тот, который лучше всего соответствует философии SVN, называется ветвями.

Имея это в виду и связывая это с идеей стабильного процесса обеспечения качества (QA) и разработки (dev), вот что я бы порекомендовал:

Один репозиторий с именем «Stable» для каждого проекта. Несколько репозиториев QA на проект и тонны Dev на проект.
Теги и ветви имен определяются только в «стабильном» репо или, в конечном итоге, в «QA».Репозитории "Dev" могут обрабатывать их по-разному, не причиняя вреда.
Вы никогда не продвигаете репо «QA» или «Stable», они вытягивают или интегрируют пакеты или исправления, и за каждое из них отвечает один человек.

Пример: MyProject-1.0

 [STABLE Repository, pulls from any/all QA]
  - MyProject-1.0

 [QA Repositories, branched from STABLE, pulls from any/all DEV ]
  - QA_MyProject-001 (Person A)
  - QA_MyProject-002 (Person B)
  - QA_MyProject-003 (Person C)
            ...
  - QA_MyProject-### (Person #)

 [DEV Repositories, branched from STABLE or QA]
  - DEV_MyProject-001 (Feature X) 
  - DEV_MyProject-002 (Feature Y)
  - DEV_MyProject-003 (Feature Z)
            ...
  - DEV_MyProject-### (Feature #)

  1. DEV completes feature(s)
  2. QA pulls feature(s) from DEV
  3. STABLE pulls from all approved QA(s) (consolidating all changes)