svn - 跨多个项目的 Subversion 修订号

Question

当使用 Subversion (svn) 对多个项目进行源代码控制时，我注意到修订号在我所有项目的目录中都会增加。为了说明我的 svn 布局（使用虚构的项目名称）：

    /NinjaProg/分支机构
              /标签
              /树干
    /StealthApp/分支机构
               /标签
               /树干
    /SnailApp/分支机构
             /标签
             /树干

当我对 Ninja Program 的主干执行提交时，假设我知道它已更新到修订版 7。第二天假设我对 Stealth 应用程序进行了小改动，它以修订版 8 的形式返回。

问题是这样的：在使用一个 Subversion 服务器维护多个项目时，是否普遍接受的做法是在所有项目中增加不相关项目的修订号？还是我做错了，应该为每个项目创建单独的存储库？还是完全是别的东西？

编辑：我延迟标记答案，因为很明显这两种方法都有原因，即使这个问题首先出现，我想指出一些最终提出相同问题的其他问题：

我应该将所有项目存储在一个存储库中还是多个存储库中？

一个 SVN 存储库还是多个？

score 9 · Accepted Answer

我很惊讶没有人提到这在使用 Subversion 的版本控制中进行了讨论，该版本可在线免费获得，请点击此处。

我不久前阅读了这个问题，这似乎是个人选择的问题，这里有一篇关于这个主题的好博文。编辑：由于博客似乎已关闭，（此处为存档版本），这里有一些 Mark Phippard 不得不说的关于这个主题的内容。

这些是单一存储库方法的一些优点。

简化管理。一组要部署的钩子。一个要备份的存储库。等等

分支/标签的灵活性。将代码全部放在一个存储库中，可以更轻松地创建涉及多个项目的分支或标签。

轻松移动代码。也许您想从一个项目中提取一段代码并在另一个项目中使用它，或者将其变成多个项目的库。在同一存储库中移动代码并保留该过程中代码的历史记录很容易。

以下是单存储库方法的一些缺点，多存储库方法的优点。

尺寸。处理许多较小的存储库可能比处理一个大存储库更容易。例如，如果您停用一个项目，您只需将存储库存档到媒体并将其从磁盘中删除并释放存储空间。也许您出于某种原因需要转储/加载存储库，例如利用新的 Subversion 功能。如果它是一个较小的存储库，这更容易做到并且影响更小。即使您最终想要对所有存储库执行此操作，如果没有迫切需要一次执行所有存储库，一次执行一个存储库的影响也会较小。

全局修订号。尽管这不应该是一个问题，但有些人认为它是一个问题，并且不喜欢看到存储库上的修订号提前，并且不活动的项目在其修订历史记录中有很大的差距。

访问控制。虽然 Subversion 的 authz 机制允许您根据需要限制对存储库部分的访问，但在存储库级别执行此操作仍然更容易。如果您有一个只有少数人可以访问的项目，则使用该项目的单个存储库更容易做到这一点。

行政灵活性。如果您有多个存储库，那么根据存储库/项目的需要实现不同的钩子脚本会更容易。如果您想要统一的钩子脚本，那么单个存储库可能会更好，但是如果每个项目都想要自己的提交电子邮件样式，那么将这些项目放在单独的存储库中会更容易

当您真正考虑时，多项目存储库中的修订号会变高，但您不会用完。请记住，您可以查看子目录上的历史记录并快速查看与项目相关的所有修订号。

score 6 · Accepted Answer

我认为强烈建议您为每个项目创建单独的存储库。如果只是为了避免你正在谈论的场景。

使用版本控制，尤其是 Subversion，您可以轻松地将存储库的各个部分检出到另一个工作副本中，然后将它们提交回各自的存储库。这使您可以将它们清楚地分开和区分，同时为您提供很大的灵活性。一旦你进入 SVN 多一点（我假设你是新人。）你可以开始使用钩子，我可能会看到你的设置会在哪里变得困难。如果权限对您很重要，那么单个存储库可能会比必要的更困难。

此外，如果您担心设置每个存储库会花费大量时间，请查看 Apache 配置文件的 SVNParentPath 变量。（再次，我假设您使用的是 Apache。）

score 4 · Accepted Answer

这是由于颠覆的工作方式。每个修订实际上是由该修订号标识的存储库的快照。如果您的所有项目都共享一个存储库，那么这是不可避免的。通常，根据我的经验，您会为完全不相关的项目设置单独的存储库。所以简短的回答是不，你没有做错任何事情，这是一个围绕颠覆的常见问题，但是当你考虑它如何存储存储库信息时它是有道理的。

score 4 · Accepted Answer

修订号实际上应该只是特定版本的标识符。对于一个项目来说，它是否是连续的并不重要。话虽如此，我可以理解这并不理想。

我遇到的大多数项目都是在单个存储库中设置的，并且修订 ID 以这种方式运行。我不知道任何 SVN 配置选项来改变这种行为，恕我直言，维护多个存储库似乎是不必要的开销。

score 4 · Accepted Answer

我们只有一个包含所有内容的存储库，与您的示例非常相似。

我看不出有什么问题 - 对修订号的唯一要求是它是

独特
原子
比上次入住时大

就我而言，每次提交增加 1 或 50 都没有关系。

@格罗姆：

然后每当我开始一个新项目时，我都会运行：

svnadmin create /var/www/svn/myproject

如果您只有 1 或 2 个开发人员，我可以看到这工作正常，但是如果创建新项目的人在 SVN 服务器上没有 shell 访问权限以能够在 /var/www 下创建目录，会发生什么？

score 3 · Accepted Answer

建议为每个项目使用单独的存储库。在我的 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

score 3 · Accepted Answer

嗯，在我工作的地方，我们所有的项目都在同一个存储库中。我真的没有看到将它们分开的好处，这不是创造了很多额外的工作——创建新的存储库，授予人们访问权限等吗？我想如果项目完全不相关，并且您有外部客户需要访问存储库，那么单独的存储库是有意义的。

score 3 · Accepted Answer

在我的工作场所，我们有两个存储库。一个具有公共读取访问权限，一个用于其他所有内容。我会只使用一个，但我们需要不同的公共/私人项目访问权限。

也就是说，我个人并不认为每次更新都会增加修订号的问题。修订版号可以跳过素数和偶数，仍然可以做它应该做的事情。使获得特定修订变得容易。

score 2 · Accepted Answer

如果根据其他项目更改修订号让您感到困扰，则将项目放在单独的存储库中。这是使修订号独立的唯一方法。

对我来说，使用不同存储库的主要原因是为用户提供单独的访问控制和/或使用不同的钩子脚本。

score 2 · Accepted Answer

也许最好不必为每个“项目”制作一个仓库，而是每个“解决方案”制作一个仓库（使用 Visual Studio 术语）。如果您在不同的文件夹中有一堆“项目”，但它们彼此相关，那么将它们放在同一个 repo 中。

score 1 · Accepted Answer

我为每个存储库存储一个项目，并且像之前对此颠覆问题的评论者一样，我将共享项目标记为外部，以便它们仅在源代码控制中一次。

我刚刚开始添加一个 CI 构建服务器 (CruiseControl.NET)，所以我将不得不看看这一切是如何进行的，但如果我的构建脚本是正确的，那应该不是问题。

不过，除了外观之外，这确实是一个偏好问题（在我看来）。

score 1 · Accepted Answer

当您真正考虑时，多项目存储库中的修订号会变高，但您不会用完。请记住，您可以查看子目录上的历史记录并快速查看与项目相关的所有修订号。

实际上，如果您构建 Microsoft 代码，并且您使用 svn 修订号作为版本字符串的一部分，那么您可能会用完。如果版本字符串的任何部分大于 65535，Microsoft 编译器将抛出一个错误......在我们的例子中，我们有一个巨大的版本 68876 的存储库，我们只是碰壁了。

score 0 · Accepted Answer

每个项目一个存储库。

Steven Murawski 对 CC.NET 的评论很有趣。如果您需要指定多个源代码控制存储库，我很想听听它是如何工作的。

score 0 · Accepted Answer

@Daniel Fone：SVN 文档推荐每个存储库一个项目，所以这绝对是创建者想要的方式。由于您可以让一台服务器（apache 或 svnserve）维护多个存储库，因此我从未遇到过开销过多的问题。使用VisualSVN Server，安装 apache 服务器和配置多个存储库是一件轻而易举的事。

score 0 · Accepted Answer

我不确定 SVN 文档是否真的推荐每个存储库一个项目。他们大多谈论每条路径的优点和缺点。我碰巧使用了三个不同的存储库，一个用于 7 或 8 个相关的项目，这使得能够发送所有项目的兼容副本非常好，只需从一个修订版构建（或通过查看来验证它们是否兼容）在每个修订号）。第二个存储库有另一组相关的项目和文档，而第三个存储库要小得多。这让我们可以利用这样一个事实，即相关项目可以由单个修订号管理，但不相关的项目不会影响它们的存储库。

score 0 · Accepted Answer

修订号没有语义用途。唯一的问题是，它们是按顺序排列的。如果您转储项目并将其导入另一个存储库，您的版本可以获得新的修订号。所以永远不要使用修订号来标记你的版本或类似的东西。为发布制作标签（相关修订的副本）。

score 0 · Accepted Answer

我以前的公司也有同样的问题，他们曾经在一个存储库中运行大约 50 个项目，而在同一个项目上工作是一场噩梦，因为在进行 svn 更新时，其他人会诅咒....哈哈...

我学到的一件事总是效果最好，一个项目一个回购......你永远不会后悔。

svn - 跨多个项目的 Subversion 修订号

17 回答 17

Related

Reference