我的公司有一个大型Subversion（SVN）存储库，由于各种原因，我们正在考虑迁移到Mercurial（HG）。我希望能够为我们的情况学习“最佳实践”的想法。
我们的SVN存储库相当单一，看起来像这样：
目前，我们是我们任何代码和产品的唯一消费者。存储库中的其他资源，但转换原因的部分原因是我们可能/将与其他消费者共享我们代码的某些部分。因此，我们的项目将分为以下几类可访问性：
此外，为了强调这一点，一些代码（例如，上面SVN存储库示例中的Python_Shared_Code文件夹）是跨项目共享的，因此应该可以轻松地用于任何Python项目（私有代码），并且可能需要适用于外部消费者（共享代码或公共代码）。
我有一些想法，我认为我会如何解决这个问题，但我希望在继续迁移之前先了解一些想法。
更新：我不确定从上面是否清楚，但特别是，我正在寻找有关HG存储库布局及其如何互动的建议。
更新：这个问题与之前提出的其他几个问题类似 - 但并不完全相同：
与之前问题的主要区别在于“可访问性”和共享代码的概念。一些项目是相互关联的（例如，Python_Project_1和Python_Shared_Code），并且一些项目可能需要与外部实体共享（即，共享代码和公共代码）。已经讨论了将单个单片SVN存储库拆分为多个HG存储库的概念，但我还没有找到任何先前讨论过的共享类型的概念。
答案 0 :(得分：1)
我会说this answer做得很好，建议每个模块单独回购。
在this answer中，我建议使用子版本（are ready）或（我的偏好）构建系统，该系统从常春藤等本地构建框中提取依赖项。