我应该使用多少个存储库来在版本控制下维护我的脚本？
我主要为自己编写小程序，但最近，我开始为团队中的同事编写代码。为此，我开始使用 Mercurial 存储库以某种形式的版本控制（特别是 Windows 上的 Tortoise-Hg）来维护我的代码。我有许多小脚本，每个脚本都在自己的目录中，全部位于一个存储库下。然而，在阅读 Joel 的 Hg 教程时，我尝试为我的一个较大脚本克隆一个目录，以创建一个“稳定”的目录版本并发现我无法做到这一点，因为该目录本身不是存储库。
因此，我假设（如果我错了，请纠正我）为了正确使用克隆，我必须为每个脚本/目录创建一个存储库。但是..这会是一个“好主意”还是未来等待发生的维护噩梦？
简而言之，我是否将所有（不相关的）脚本保存在一个存储库中，还是应该为每个脚本创建一个存储库？或者一些未知的第三种选择？
I mainly code small programs for myself, but recently, I've been starting to code for my peers on my team. To that end, I've started using a Mercurial repository to maintain my code in some form of version control (specifically, Tortoise-Hg on Windows). I have many small scripts, each in their own directory, all under one repository. However, while reading Joel's Hg Tutorial, I tried cloning a directory for one of my bigger scripts to create a "stable" version and found I couldn't do it because the directory wasn't itself a repository.
So, I assume (and please correct me if I'm mistaken) that in order to use cloning properly, I'd have to create a repository for each script/directory. But.. would that be a "good idea" or a future maintenance nightmare waiting to happen?
Succinctly, do I keep all my (unrelated) scripts in one repository, or should I create a repository for each? Or some unknown third option?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
对您在某个时候可能想要独立使用的所有内容使用单独的存储库。将来合并存储库非常容易，而将它们分开则困难得多。 subrepos 功能（如 svn externals）甚至可以让您创建一个包含所有小项目的伞式存储库如果您仍然希望能够在单个命令中克隆它，请查看 repos。
Use separate repos for everything that you might want to use independently at some point. It's very easy to combine repos in the future and much harder to pull them apart. The subrepos feature (like svn externals) even lets you make an umbrella repo that includes all the small repos if that's still something you'd like to be able to clone in a single command.
原则上，单独的存储库听起来很棒。但我不确定这种方法是否可以扩展。仅在我的
~/bin目录中我就编写了一千多个脚本。这些都存储在一个存储库中。这些脚本很小：平均长度为 150 行，但这具有误导性——只有大约 15% 的脚本超过 100 行。我看不到将它们放在单独的存储库中的用例。如果我想与其他开发人员共享，我通常只发送源代码。它们的变化并不大：一半的脚本自 2005 年 6 月以来就没有被修改过，只有 5% 的脚本在过去六个月中被修改过。因此，大部分代码相当稳定，没有太多错误修复，并且历史记录并不有趣。
我会选择一个存储库，直到您看到有明确的需求为止。
In principle, separate repositories sound great. But I'm not sure this approach scales. I have written over one thousand scripts in my
~/bindirectory alone. These are all stored in a single repository. These scripts are small: the average length is 150 lines, but this is misleading—only about 15% of the scripts are over 100 lines.I can't see the use case for putting them in separate repos. If I want to share with fellow developers, I generally just send source code. They don't change a lot: half the scripts haven't been modified since June 2005, and only 5% have been modified in the last six months. So most of the code is reasonably stable, there aren't a lot of bug fixes, and the history isn't interesting.
I would go with a single repo until you see a demonstrated need.
为每个项目和小型项目的每个逻辑块使用一个存储库。
在我看来，hg subrepo 功能尚未准备好投入使用；相当多的核心 hg 命令不理解子存储库，因此您可以轻松地攻击自己，尤其是使用共享代码。您可以在 hg 的最新补丁说明中找到有关子存储库的更多信息。
Use a repository for each project and for each logical block of mini-projects.
hg subrepo functionality is not ready for prime-time yet, in my opinion; quite a few of the core hg commands don't understand subrepos and therefore you can stab yourself quite handily, especially with shared code. You can find more info about subrepos in the latest patch notes for hg.
为每个实际目录创建一个单独的存储库可能是一个好主意，因为它将它与其余代码分开。正如编码中的模块化是有益的一样，存储库中的模块化也是有益的。如果您想在 GitHub 等网站上发布您的脚本之一，如果存储库已经是单独的，那就更容易了。
但是，如果您有一堆只有一个文件长的小脚本，您可能可以将它们保存在单个存储库中。但是，如果您想发布它的修订版，则必须立即发布所有修订版。
Creating a separate repository for each actual directory would probably be a good idea, as it separates it from the rest of your code. Just as modularity in coding is beneficial, so is modularity in repositories. If you wanted to publish one of your scripts on something like GitHub, it is easier if the repos are already separate.
However, if you have a bunch of small scripts that are one file long, you probably are fine keeping them under a single repository. However, if you ever wanted to release the revisions of it, you would have to release all of them at once.