我主要为自己编写小程序，但最近，我开始为团队中的同事编写代码。为此，我开始使用 Mercurial 存储库以某种形式的版本控制（特别是 Windows 上的 Tortoise-Hg）维护我的代码。我有许多小脚本，每个都在自己的目录中，都在一个存储库下。然而，在阅读Joel 的 Hg 教程时，我尝试为我的一个更大的脚本克隆一个目录以创建一个“稳定”版本，但我发现我做不到，因为该目录本身不是存储库。
所以，我假设（如果我弄错了，请纠正我）为了正确使用克隆，我必须为每个脚本/目录创建一个存储库。但是..这是一个“好主意”还是等待发生的未来维护噩梦？
简而言之，我是将所有（不相关的）脚本保存在一个存储库中，还是应该为每个脚本创建一个存储库？还是一些未知的第三种选择？
对于您在某些时候可能想要独立使用的所有内容，请使用单独的存储库。将来合并回购非常容易，而将它们分开则要困难得多。subrepos功能（如 svn externals）甚至可以让您创建一个包含所有小型 repos 的伞式 repo，如果您仍然希望能够在单个命令中克隆的话。
原则上，单独的存储库听起来很棒。但我不确定这种方法是否可以扩展。~/bin仅在我的目录中，我就编写了超过一千个脚本。这些都存储在一个存储库中。这些脚本很小：平均长度为 150 行，但这是一种误导——只有大约 15% 的脚本超过 100 行。
我看不到将它们放在单独的存储库中的用例。如果我想与其他开发人员分享，我通常只是发送源代码。它们没有太大变化：自 2005 年 6 月以来，一半的脚本没有被修改过，而在过去的六个月中只有 5% 的脚本被修改过。所以大部分代码相当稳定，没有很多错误修复，历史也不有趣。
我会选择一个 repo，直到你看到一个明显的需求。
为每个项目和迷你项目的每个逻辑块使用一个存储库。
在我看来， hg subrepo 功能还没有准备好迎接黄金时段；相当多的核心 hg 命令不理解 subrepos，因此您可以非常方便地刺伤自己，尤其是使用共享代码。您可以在 hg 的最新补丁说明中找到有关 subrepos 的更多信息。
为每个实际目录创建一个单独的存储库可能是一个好主意，因为它将它与您的其余代码分开。正如编码中的模块化是有益的一样，存储库中的模块化也是如此。如果您想在 GitHub 之类的地方发布您的脚本之一，那么如果这些存储库已经是独立的，那就更容易了。
但是，如果您有一堆只有一个文件长的小脚本，您可能可以将它们保存在一个存储库中。但是，如果您想发布它的修订版，则必须立即发布所有修订版。