我应该使用多少个存储库来维护版本控制下的脚本？

Question

我主要为自己编写小程序代码，但最近，我开始为我的团队中的同行编写代码。为此，我开始使用Mercurial存储库来维护我的代码以某种形式的版本控制（特别是Windows上的Tortoise-Hg）。我有许多小脚本，每个脚本都在自己的目录中，都在一个存储库下。但是，在阅读Joel's Hg Tutorial时，我尝试为我的一个较大的脚本克隆一个目录来创建一个“稳定”的版本，并发现我无法这样做，因为该目录本身并不是一个存储库。

所以，我假设（如果我弄错了，请纠正我），为了正确使用克隆，我必须为每个脚本/目录创建一个存储库。但是......这会是一个“好主意”还是未来的维护噩梦等待发生？

简洁地说，我是否将所有（不相关的）脚本保存在一个存储库中，还是应该为每个存储库创建一个存储库？还是一些未知的第三种选择？

Answer 1

对于您可能希望在某些时候单独使用的所有内容，请使用单独的repos。在将来组合回购非常容易，并且更难将它们分开。 subrepos功能（如svn externals）甚至可以让你制作一个包含所有小回购的伞形回购，如果你仍然希望能够在一个命令中克隆它。

Answer 2

原则上，单独的存储库听起来很棒。但我不确定这种方法可以扩展。我单独在~/bin目录中编写了超过一千个脚本。这些都存储在单个存储库中。这些脚本 small ：平均长度为150行，但这是误导性的 - 只有大约15％的脚本超过100行。

我看不到将它们放在单独的回购中的用例。如果我想与其他开发人员分享，我通常只是发送源代码。它们没有太大变化：自2005年6月以来，一半的脚本没有被修改过，过去六个月中只有5％被修改过。因此大多数代码都相当稳定，没有很多错误修复，历史也没有意义。

我会选择一个回购，直到你看到明确的需求为止。

Answer 3

为每个项目和迷你项目的每个逻辑块使用存储库。

hg subrepo功能尚未准备好黄金时段，在我看来;相当多的核心hg命令无法理解subrepos，因此你可以非常轻松地刺伤自己，特别是使用共享代码。您可以在hg的最新补丁说明中找到有关subrepos的更多信息。

Answer 4

为每个实际目录创建一个单独的存储库可能是一个好主意，因为它将它与其余代码分开。正如编码中的模块化是有益的，存储库中的模块化也是如此。如果你想在GitHub之类的东西上发布你的一个脚本，那么如果repos已经分开就更容易了。

但是，如果你有一堆长度为一个文件的小脚本，你可能很好将它们保存在一个存储库中。但是，如果您想要发布它的修订版，则必须立即释放所有修订版。