【发布时间】：2010-03-04 18:09:09
【问题描述】：
我的公司有一个大型 Subversion (SVN) 存储库，出于各种原因，我们正在考虑迁移到 Mercurial (HG)。我希望学习适合我们情况的“最佳实践”想法。
我们的 SVN 存储库相当单一，看起来像这样：
- 后备箱
- Python_Project_1
- Python_Project_2
- Python_Shared_Code
- Flex_Code
- ObjC_Code
- ...
- 分支机构
- Python_Project_1_Release_1.0.x
- ...
- 标签
- Python_Project_1_Release_1.0.0
- ...
目前，我们是存储库中任何代码和其他资源的唯一消费者，但切换的部分原因是我们可能/将与其他消费者共享部分代码。因此，我们的项目将分为以下几类可访问性：
- 私人密码（仅供我们使用）
- 共享代码（与非公共合作伙伴共享）
- 公共代码（通过开源许可证共享）
此外，为了强调这一点，一些代码（例如，上面 SVN 存储库示例中的 Python_Shared_Code 文件夹）在项目之间共享，因此应该可以轻松地用于任何 Python 项目（私有代码），并且可能需要可供外部消费者使用（共享代码或公共代码）。
我对如何布局有一些想法，但我想在继续迁移之前获得外部想法。
更新：我不确定从上面是否清楚，但特别是，我正在寻找有关 HG 存储库的布局以及它们如何交互的建议。
更新：这个问题与之前提出的其他几个问题相似——但不完全相同：
与前面问题的主要区别在于“可访问性”和共享代码的概念。有些项目是相互关联的（例如，Python_Project_1 和 Python_Shared_Code），有些可能需要与外部实体共享（例如，共享代码和公共代码）。已经讨论了将单个单一的 SVN 存储库拆分为多个 HG 存储库的概念，但我还没有发现前面讨论过的任何一种共享类型的概念。
【问题讨论】：
-
嗯，看来你可以用 hg-svn 做一个空运行？
-
对不起，显然我没有说清楚。我实际上并不担心如何进行迁移，而是更关心迁移后的布局。我已在问题末尾添加了更新以澄清。
-
正如您所注意到的，这显然是一个重复的问题，并且其他问题有一些很好的答案，可以完全涵盖您的情况。如果您发现它们还不够，也许可以链接到它们并说出您的情况有何不同。因为你只会从骗子那里得到很多复制粘贴的答案，最终有人会关闭它。
-
感谢您的评论。我已经对问题进行了澄清，解释了为什么我认为这与以前提出的问题不同。 （如果它与我尚未找到的问题重复，指向原始问题的指针也很有用。）
-
感谢您的澄清。我会在下面插话。
标签： svn mercurial migration repository