当使用 Subversion (svn) 对多个项目进行源代码控制时，我注意到我的所有项目目录中的修订号都会增加。为了说明我的 svn 布局（使用虚构的项目名称）：
/NinjaProg/分支机构 /标签 /树干 /StealthApp/分支机构 /标签 /树干 /SnailApp/分支机构 /标签 /树干当我对 Ninja Program 的主干执行提交时，假设我知道它已更新到修订版 7。第二天假设我对 Stealth 应用程序进行了小改动，它以修订版的形式返回8.
问题是这样的：在使用一个 Subversion 服务器维护多个项目时，在所有项目中增加不相关项目的修订号是否是普遍接受的做法？ 还是我做错了并且应该为每个项目创建单独的存储库？还是完全是另外一回事？
编辑：我延迟标记答案，因为很明显这两种方法都有原因，即使这个问题首先出现，我想指出其他一些问题最终都在问同样的问题：
【问题讨论】：
标签： svn version-control repository
我很惊讶没有人提到这在带有 Subversion 的版本控制中讨论过，它可以在线免费获得，here。
我不久前阅读了这个问题，这似乎是个人选择的问题，有一篇关于主题 here 的不错的博客文章。编辑：由于博客似乎已关闭，(archived version here)，以下是 Mark Phippard 不得不说的一些内容。
这些是单一存储库方法的一些优点。
- 简化管理。一组要部署的钩子。一个要备份的存储库。等
- 分支/标签的灵活性。将代码全部放在一个存储库中，可以更轻松地创建涉及多个项目的分支或标签。
- 轻松移动代码。也许您想从一个项目中提取一段代码并在另一个项目中使用它，或者将其变成多个项目的库。在同一存储库中移动代码并保留该过程中代码的历史记录很容易。
以下是单存储库方法的一些缺点，多存储库方法的优点。
- 尺寸。处理许多较小的存储库可能比处理一个大存储库更容易。例如，如果您停用一个项目，您只需将存储库存档到媒体并将其从磁盘中删除并释放存储空间。也许您出于某种原因需要转储/加载存储库，例如利用新的 Subversion 功能。如果它是一个较小的存储库，这更容易做到并且影响更小。即使您最终想要对所有存储库执行此操作，如果没有迫切需要一次执行所有存储库，一次执行一个存储库的影响也会较小。
- 全局修订号。尽管这不应该是一个问题，但有些人认为这是一个问题，并且不希望看到存储库上的修订号提前，并且不活动的项目在其修订历史记录中有很大的差距。
- 访问控制。虽然 Subversion 的 authz 机制允许您根据需要限制对存储库部分的访问，但在存储库级别执行此操作仍然更容易。如果您有一个只有少数人可以访问的项目，则使用该项目的单个存储库更容易做到这一点。
- 管理灵活性。如果您有多个存储库，那么根据存储库/项目的需要实现不同的钩子脚本会更容易。如果您想要统一的钩子脚本，那么单个存储库可能会更好，但如果每个项目都想要自己的提交电子邮件样式，那么将这些项目放在单独的存储库中会更容易
当您真正考虑时，多项目存储库中的修订号会越来越高，但您不会用完。请记住，您可以查看子目录上的历史记录并快速查看与项目相关的所有修订号。
【讨论】：
我认为强烈建议您为每个项目创建单独的存储库。如果只是为了避免您正在谈论的情况。
使用版本控制，尤其是 Subversion，您可以轻松地将存储库的各个部分检出到另一个工作副本中，然后将它们提交回各自的存储库。这使您可以将它们清楚地分开和区分，同时为您提供很大的灵活性。一旦你更深入地了解 SVN（我假设你是新手），你就可以开始使用钩子了，我可能会看到你的设置在哪里可能会遇到困难。如果权限对您很重要，那么单个存储库可能会比必要的更困难。
此外，如果您担心设置每个存储库会花费大量时间，请查看 Apache 配置文件的 SVNParentPath 变量。 （再次，我假设您使用的是 Apache。）
【讨论】：
这是由于颠覆的工作方式。每个修订版实际上是由该修订号标识的存储库的快照。如果您的所有项目都共享一个存储库，那么这是不可避免的。通常，根据我的经验，您会为完全不相关的项目设置单独的存储库。所以简短的回答是不，你没有做错任何事情，这是一个围绕颠覆的常见问题，但当你考虑它如何存储存储库信息时，它是有道理的。
【讨论】：
修订号实际上应该只是特定版本的标识符。对于一个项目来说，它是否是连续的并不重要。话虽如此，我可以理解它并不理想。
我遇到的大多数项目都是在单个存储库中设置的，并且修订 ID 以这种方式运行。我不知道任何 SVN 配置选项来改变这种行为，恕我直言，维护多个存储库似乎是不必要的开销。
【讨论】：
我们只有一个包含所有内容的存储库，与您的示例非常相似。
我看不出有什么问题 - 对修订号的唯一要求是它是
就我而言，每次提交增加 1 或 50 都没有关系。
@grom：
然后每当我开始一个新项目时，我都会运行：
svnadmin create /var/www/svn/myproject
如果您只有 1 或 2 个开发人员，我可以看到这工作正常，但是如果创建新项目的人没有 SVN 服务器上的 shell 访问权限以能够在 /var 下创建目录，会发生什么情况/万维网？
【讨论】：
建议为每个项目使用单独的存储库。在我的 Apache conf.d 目录中，我的 subversion.conf 包含：
<Location /svn>
DAV svn
SVNParentPath /var/www/svn
AuthType Basic
AuthName "Subversion Repository"
AuthUserFile /var/www/svn/password
Require valid-user
</Location>
然后每当我开始一个新项目时，我都会运行：
svnadmin create /var/www/svn/myproject
【讨论】：
嗯，在我工作的地方，我们所有的项目都在同一个存储库中。我真的没有看到将它们分开的好处，这不只是创造了很多额外的工作 - 创建新的存储库，授予人们访问权限等吗？我想如果项目完全不相关，并且你有外部客户需要访问存储库，那么单独的存储库是有意义的。
【讨论】：
在我的工作场所，我们有两个存储库。一个具有公共读取访问权限，一个用于其他所有内容。我会只使用一个，但我们需要不同的公共/私人项目访问权限。
也就是说，我个人并不认为每次更新都会增加修订号的问题。修订号可以跳过素数和偶数，仍然可以做它应该做的事情。轻松获得特定修订版。
【讨论】：
如果根据其他项目更改修订号让您感到困扰，请将这些项目放在单独的存储库中。这是使修订号独立的唯一方法。
对我来说，使用不同存储库的主要原因是为用户提供单独的访问控制和/或使用不同的钩子脚本。
【讨论】：
也许最好不必为每个“项目”创建一个存储库，而是每个“解决方案”创建一个存储库（使用 Visual Studio 术语）。如果您在不同的文件夹中有一堆“项目”，但它们彼此相关，那么请将它们放在同一个 repo 中。
【讨论】：
我在每个存储库中存储一个项目，并且像以前的 commenter 在此 subversion question 上一样，我将共享项目标记为外部，因此它们仅在源代码控制中一次。
我刚刚开始添加一个 CI 构建服务器 (CruiseControl.NET)，所以我必须看看它是如何工作的，但如果我的构建脚本是正确的，那应该不是问题。
不过，除了外观，这确实是一个偏好问题（在我看来）。
【讨论】：
当您真正考虑时，修订号是倍数 项目存储库会变高，但你不会运行 出去。请记住，您可以查看子目录的历史记录，并且 快速查看与项目相关的所有修订号。
实际上，如果您构建 Microsoft 代码，并且您使用 svn 修订号作为版本字符串的一部分，那么您可能会用完。如果版本字符串的任何部分大于 65535，Microsoft 编译器将抛出一个错误......在我们的例子中，我们有一个巨大的版本 68876 的存储库，我们只是碰壁了。
【讨论】：
每个项目一个存储库。
Steven Murawski 关于 CC.NET 的评论很有趣。如果您需要指定多个源代码控制存储库，我很想知道它是如何工作的。
【讨论】：
@Daniel Fone：SVN 文档建议每个存储库一个项目，所以这绝对是创建者想要的方式。由于您可以让一台服务器（apache 或 svnserve）维护多个存储库，因此我从未遇到过开销过多的问题。使用VisualSVN Server，安装 apache 服务器和配置多个存储库是轻而易举的事。
【讨论】：
我不确定 SVN 文档是否真的推荐每个存储库一个项目。他们大多谈论每条路径的优点和缺点。我碰巧使用了三个不同的存储库，一个用于 7 个或 8 个相关的项目，这使得能够发送所有项目的兼容副本非常好，只需从一个修订版构建（或通过查看来验证它们是否兼容）在每个修订号）。第二个存储库有另一组相关的项目和文档，而第三个存储库要小得多。这让我们可以利用这样一个事实，即相关项目可以由单个修订号管理，但不相关的项目不会影响它们的存储库。
【讨论】：
修订号没有语义用途。唯一的问题是，它们是按顺序排列的。如果您转储项目并将其导入另一个存储库，您的版本可以获得新的修订号。所以切勿使用修订号来标记您的版本或类似的东西。为发布制作标签（相关修订的副本）。
【讨论】：
在我以前的公司也遇到过同样的问题，他们曾经在一个存储库中运行大约 50 个项目，而在相同的项目上工作简直是一场噩梦，因为在进行 svn 更新时，其他人会诅咒..哈哈.. .
我学到的一件事总是效果最好，一个项目一个回购......你永远不会后悔。
【讨论】：