mercurial用例解决方案

Question

我参与的项目有很多小模块，它们由不同的developers.We管理，目前正在使用svn，但希望切换到mercurial，因为我们需要到客户端站点进行一些开发，因此管理版本变得困难。

但是完整的主干很大，大约4-5 GB，为所有模块创建一个存储库意味着如果我需要捆绑存储库，我需要移动这个4-5 GB的文件。而且我不能备份.hg文件夹所在的一个基本文件夹中的较小模块(因为它们没有.hg文件夹)，因为它不会为我提供任何从备份的模块(文件夹)进行备份的方法。那么，当一个项目有许多模块，并且说……所有开发人员都带着自己的模块(将要传输的数据大小保持在最小)，在他们想要的任何地方编写代码，然后带回它并合并他们的分支。

我脑海中浮现的一个明显的解决方案是，每个模块都变成了代码库，但当一个集成产品将是released..what版本时，这将很难管理。因为所有模块都有自己的版本历史记录？？

一个更明显的情况是，如果我将完整的svn历史记录转换为mercurial..then，如果在主干上完成转换，它将生成一个repo，但是由于巨大的size..and，每个模块所有者每次都带着这个巨大的捆绑包是没有意义的。

那么有什么建议吗？

谢谢。

Answer 1

Tonfa在评论中提到了这一点，但我会将其作为答案:使用Mercurial的Submodule Support。它说是经验性的，但它已经通过了1.3版本的几个月，没有重大的错误或变化，所以我怀疑它进入了任何即将到来的变化都将向后兼容的区域。

此外，如果你有一些非常大的文件(> 10MB)膨胀了代码库，你可以使用Big Files Extension将它们移出直接控制，但仍然跟踪它们的版本。

不过，一般来说，我发现如果我的构建脚本足够全面，它们可以下载大型的、非手动编辑的资产，而不是将它们放在源代码控制中，那么repos不会增长到4 GB或5 GB --这是很大的KLoC。也许这次迁移是使用Ivy之类的依赖项下载工具或适合您的开发环境的好时机。

Answer 2

在网站上，我们把除了MP3和FLV文件之外的所有文件都放在mercurial下，而且很少会超过300MB。此外，磁盘也很便宜。如果您与客户站点之间存在带宽问题(或某种安全问题)，您可能想要将整个树克隆到一个拇指驱动器上，转到客户站点并进行黑客攻击，然后回家并进行合并更改。

Mercurial从根本上改变了我看待版本控制的方式。像这样的事情曾经是件大事现在..。嗯。