SVN用户推荐的Mercurial存储库/文件夹结构 [英] Recommended Mercurial repository/folder structure for an SVN user

问题描述

我正在对Hg进行试验，以期远离SVN，但希望就如何构建Hg存储库提出一些意见.我来自SVN背景(可能影响了我的工作方式！)，我的存储库当前看起来像这样:

I am experimenting with Hg with a view to moving away from SVN but wanted some opinions on how I should structure my Hg repository. I come from a SVN background (which may of tainted my outlook on how this should work!) and my repository currently looks something like this:

Project1
  trunk
  branches
    1.0
    1.1
Project2
  trunk

等这似乎是构建SVN信息库的传统"方式.

etc. This seems to be the 'traditional' way to structure an SVN repository.

我应该如何用汞重现这一点?为了给这个问题加点儿趣味，我喜欢稳定"，"qa"和"dev"存储库/文件夹的想法，并希望在可能的情况下引入它.

How should I reproduce this with Hg? To spice this up a little I like the idea of 'stable', 'qa' and 'dev' repositories/folders and would like to introduce this if possible.

我是汞初学者，因此欢迎您提供任何帮助或建议.

I am an Hg beginner so any help or advice is welcome.

推荐答案

Subversion(SVN)和Mercurial(HG)存储库(简称repo)之间存在一些结构差异，这意味着您将如何设计"层次结构:

There are several structural differences between a Subversion (SVN) and Mercurial (HG) repository, or repo for short, implies how you'll "design" your hierarchy:

• Mercurial在每个存储库中只有一个项目的情况下效果更好:由于您始终必须克隆整个存储库，因此在单个存储库中拥有多个项目可能会对克隆时间和克隆时间产生重大影响推/拉操作，因为您每次都必须同步在其他项目上完成的所有工作.
• SVN没有标签/分支的强"概念，而Mercurial :在SVN中(在撰写本文时)，每个分支，每个标签基本上都是一个副本.给定项目/文件夹/任何内容.推荐的trunk/branches/tags结构可帮助您找到副本"，仅此而已.另一方面，分支和标签的定义很明确.标签实际上是您在特定修订版中使用的名称，您可以索取所有现有标签.对于分支机构，您会看到有许多处理分支的方法，但最适合SVN哲学的方法称为分支.

• Mercurial works better with only one project per repository: Because you always have to clone the entire repository, having multiple project in a single repository might have a big impact on the cloning time as well as on the pushing/pulling operations, as you'll have to synchronize all the job that was done on other projects than yours each time.
• SVN does not have a "strong" notion of tagging/branching, while Mercurial does: In SVN (at the time of writing), each branch, each tag, is basically a copy of a given project/folder/whatever. The recommended trunk/branches/tags structure is there to help you to find your "copies" back, no more. On the other side, branches and tags are well defined in mercurial. A tag is really a name that you put on a particular revision, and you can ask for all the existing tags. For branches, you'll see that there are MANY ways to handle them, but the one that fits best to the SVN philosophy, are named branches.

考虑到这一点，并结合您对稳定，质量保证(QA)和开发(dev)流程的想法，以下是我的建议:

With that in mind, and coupling it with you idea of stable, quality assurance (QA), and development (dev) process, here is what I would recommend:

• 每个项目一个名为稳定"的存储库.每个项目有几个"QA"存储库，每个项目有数吨"Dev".
• 标记和名称分支仅由稳定"存储库定义，或最终由"QA"定义. "Dev"存储库可以以不同的方式处理它们，而不会造成损害.
• 您永远不会推动"QA"或稳定"回购，他们会拉动它们，或者将包或补丁集成在一起，并且每个人都由一个人负责.

示例: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)

这篇关于SVN用户推荐的Mercurial存储库/文件夹结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！