（又一个）从 SVN 存储库到 HG 存储库的最佳转换是什么？
我的公司有一个大型 Subversion (SVN) 存储库，出于各种原因，我们正在考虑迁移到 Mercurial (HG)。我希望学习适合我们情况的“最佳实践”想法。
我们的 SVN 存储库相当单一，看起来像这样：
- trunk
- Python_Project_1
- Python_Project_2
- Python_Shared_Code
- Flex_代码
- 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 存储库的概念，但我还没有发现任何先前讨论的任何类型共享的概念。
My company has a large Subversion (SVN) repository, and for various reasons, we are considering migrating to Mercurial (HG). I'm hoping to learn the "best practice" ideas for our situation.
Our SVN repository is fairly monolithic, and looks something like this:
- trunk
- Python_Project_1
- Python_Project_2
- Python_Shared_Code
- Flex_Code
- ObjC_Code
- ...
- branches
- Python_Project_1_Release_1.0.x
- ...
- tags
- Python_Project_1_Release_1.0.0
- ...
Currently, we are the only consumers of any of our code & other resources in the repository but part of the reason for the switch is that we may/will be sharing some portions of our code with other consumers. So, our projects will be divided into the following categories of accessibility:
- Private Code (available only to us)
- Shared Code (shared with non-public partners)
- Public Code (shared via an open source license)
Also, to highlight the point, some code (e.g., the Python_Shared_Code folder in the SVN repository example above) is shared across projects, and so should be easily available to any Python projects (Private Code), and may need to be available for external consumers (Shared Code or Public Code).
I have some ideas of how I think I would lay this out, but I'd like to get outside ideas before continuing with the migration.
Update: I'm not sure it was clear from the above, but in particular, I'm looking for suggestions regarding the layout of HG repositories and how they interact.
Update: This question is similar -- but not identical -- to a few other questions that have been previously asked:
The major difference from the previous questions is the idea of "accessibility" and shared code. Some of the projects are inter-related (e.g., Python_Project_1 and Python_Shared_Code), and some may need to be shared with external entities (i.e., Shared Code and Public Code). The concept of splitting a single monolithic SVN repository into multiple HG repositories has been discussed, but I haven't found any concept of either type of sharing previously discussed.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我想说这个答案做得很好，建议每个模块单独的存储库。
在这个答案中，我建议使用任一子存储库（其中是准备好）或（我的偏好）从本地构建框（例如ivy）提取依赖项的构建系统。
I'd say this answer does a great job suggesting separate repos per module.
And in this answer I suggest using either subrepos (which are ready) or (my preference) a build system that pulls in dependencies from a local build box such as ivy.