我参与的项目有很多由不同开发人员管理的小模块。我们目前正在使用svn但是想切换到mercurial，因为我们需要去客户端站点并进行一些开发所以很难管理版本..
但完整的主干大约4-5 GB并为所有模块创建一个单独的回购意味着如果我需要捆绑回购我需要移动这个4-5 Gigs文件..我不能采取一个较小模块的备份（因为它们没有.hg文件夹），它们位于.hg文件夹所在的一个基本文件夹中，因为它不会给我任何从备份模块（文件夹）进行评估的方式..所以什么处理这种情况的最佳方式，其中一个项目有许多模块并且说...所有开发人员都使用它们自己的模块（保持数据大小最小化），代码随时随地，然后将其恢复并合并他们的分支。
我想到的一个明显的问题是，每个模块都会成为一个回购，但是当一个集成产品被释放时，特别难以管理。该版本会引用什么版本？因为所有模块都有自己的版本历史记录??
更明显的情况是，如果我将完整的svn历史记录转换为mercurial ..那么转换如果在主干上进行，那么它会生成一个单一的仓库但是具有巨大的大小......并且每个模块所有者都使用这个巨大的捆绑包他每次都没有意义..
所以有什么建议吗？
感谢。
答案 0 :(得分：3)
Tonfa在评论中说道，但我会把它作为答案：使用Mercurial的Submodule Support。它说的是expirimental，但它已经通过1.3版本的几个月没有出现重大错误或变化，所以我怀疑它进入了即将进行的任何更改将向后兼容的区域。
此外，如果你有一些非常大的文件（> 10MB）膨胀回购，你可以使用Big Files Extension将它们移出直接控制，但仍然可以跟踪它们的版本。
总的来说，我发现，如果我使构建脚本足够全面，以便下载大量非手动编辑的资源而不是将它们放在源代码管理中，则repos不会增长到4或5 GB - 那是很多KLoC。也许这次迁移是使用依赖性下载工具（如Ivy或适用于您的开发环境的任何内容）的好时机。
答案 1 :(得分：2)
在网站上，我们将除MP3和FLV文件以外的所有内容置于mercurial之下，我们很少超过300MB。此外，磁盘很便宜。如果您和客户站点之间存在带宽问题（或某些安全问题），您可能只想将整个树克隆到拇指驱动器上，转到客户站点并进行黑客攻击，然后回家并进行合并更改。 / p>
Mercurial从根本上改变了我对版本控制的看法。像这样的东西曾经是一个大问题，现在......呃。