跨多个项目的 Subversion 修订版本号

StackOverflow https://stackoverflow.com/questions/15674

  •  08-06-2019
  •  | 
  •  

题

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

    /NinjaProg/branches
              /tags
              /trunk
    /StealthApp/branches
               /tags
               /trunk
    /SnailApp/branches
             /tags
             /trunk

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

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

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

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

一个 SVN 存储库还是多个？

有帮助吗？

解决方案

我很惊讶没有人提到这一点在 Version Control with Subversion 中进行了讨论，该版本可以在线免费获取， 这里.

我不久前读过这个问题，这似乎确实是个人选择的问题，有一篇关于这个主题的很好的博客文章 这里. 。编辑： 由于博客似乎已关闭，（存档版本在这里），以下是马克·菲帕德（Mark Phippard）就该主题不得不说的一些内容。

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

  1. 简化管理。一组要部署的挂钩。一个要备份的存储库。ETC。
  2. 分支/标签灵活性。通过将代码全部存储在一个存储库中，可以更轻松地创建涉及多个项目的分支或标签。
  3. 轻松移动代码。也许您想从一个项目中获取一段代码并在另一个项目中使用它，或者将其转换为多个项目的库。在同一存储库中移动代码并保留流程中代码的历史记录很容易。

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

  1. 尺寸。处理许多较小的存储库可能比处理一个大的存储库更容易。例如，如果您退役一个项目，您只需将存储库存档到介质并将其从磁盘中删除并释放存储空间。也许您出于某种原因需要转储/加载存储库，例如利用新的 Subversion 功能。如果存储库较小，则这更容易做到并且影响更小。即使您最终想要对所有存储库执行此操作，假设没有迫切需要一次执行所有存储库，一次执行一个存储库的影响也会较小。
  2. 全球修订号。尽管这不应该是一个问题，但有些人认为这是一个问题，并且不喜欢看到存储库中的修订号提前，也不喜欢看到不活跃的项目在其修订历史记录中存在巨大差距。
  3. 访问控制。虽然 Subversion 的 authz 机制允许您根据需要限制对存储库部分的访问，但在存储库级别执行此操作仍然更容易。如果您的项目只有少数人可以访问，则使用该项目的单个存储库可以更轻松地完成此操作。
  4. 行政灵活性。如果您有多个存储库，那么根据存储库/项目的需求实现不同的钩子脚本会更容易。如果您想要统一的挂钩脚本，那么单个存储库可能会更好，但如果每个项目都想要自己的提交电子邮件样式，那么将这些项目放在单独的存储库中会更容易

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

其他提示

我认为强烈建议您为每个项目创建单独的存储库。如果没有别的原因，只是为了避免您正在谈论的情况。

通过版本控制，尤其是 Subversion，您可以轻松地将存储库的各个部分检出到另一个工作副本中，然后将它们提交回各自的存储库。这使您可以使它们清晰分开和独特，同时给您很大的灵活性。一旦您进一步了解 SVN（我假设您是新手。），您就可以开始使用钩子，我可能会发现您的设置可能会在哪里变得困难。如果权限对您很重要，那么单个存储库可能会比必要的更困难。

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

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

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

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

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

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

  • 独特的
  • 原子
  • 比上次入住时大

就我而言，每次提交增加 1 或 50 并不重要。

@格罗姆：

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

svnadmin create /var/www/svn/myproject

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

建议每个项目使用单独的存储库。在我的 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 术语）。如果您在不同的文件夹中有一堆“项目”，但它们彼此相关，那么将它们放在同一个存储库中。

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

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

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

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

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

每个项目一个存储库。

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

@丹尼尔·丰：SVN 文档建议每个存储库一个项目，因此这绝对是创建者想要的方式。由于您可以让一台服务器（apache 或 svnserve）维护多个存储库，因此我从未遇到过开销太大的问题。和 视觉SVN服务器, ，安装 apache 服务器并配置多个存储库是小菜一碟。

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

修订号没有语义用途。唯一的问题是，它们是按顺序排列的。如果您转储项目并将其导入到另一个存储库中，您的版本可以获得新的修订号。所以 绝不 使用修订号来标记您的版本或类似内容。为版本创建标签（相关修订的副本）。

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

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

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top