颠覆多个项目的版本号

Question

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

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

当我对Ninja程序的主干执行提交时，假设我已经将其更新为修订版7.第二天让我们说我对Stealth应用程序进行了一些小改动，它将作为修订版8返回。

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

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

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

一个SVN存储库还是很多？

Answer 1

我很惊讶没有提到这在版本控制中与Subversion讨论，可以在这里免费在线获得。

我在这个问题上读了一段时间回来，这确实似乎是个人选择的问题，有关于这个问题的一个很好的博客文章在这里 。 编辑： 由于博客似乎已关闭，（ 此处存档版本 ），这里有Mark Phippard关于这个主题的一些说法。

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

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

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

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

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

Answer 2

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

使用版本控制，尤其是Subversion，您可以轻松地将存储库的各个部分检入另一个工作副本，然后将它们提交回各自的存储库。 这使您可以保持它们清晰独立和独特，同时为您提供极大的灵活性。 一旦你进入SVN多一点（我假设你是新手。）你可以开始使用钩子，我可能会看到你设置时可能会遇到困难的地方。 如果权限对您很重要，则单个存储库可能比必要更难。

此外，如果您担心需要花费大量时间来设置每个存储库，请查看Apache配置文件的SVNParentPath变量。 （同样，我假设你正在使用Apache。）

Answer 3

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

Answer 4

修订号实际上应该只是特定版本的标识符。 无论是否为项目顺序都无关紧要。 话虽如此，我可以理解它不太理想。

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

Answer 5

我们只有一个包含所有内容的存储库，几乎与您的示例完全相同。

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

• 独特
• 原子
• 比在最后一次检查时更大

就我而言，如果每次提交增加1或50，则无关紧要。

@grom：

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

svnadmin create /var/www/svn/myproject

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

Answer 6

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

Answer 7

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

Answer 8

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

也就是说，我个人没有看到每次更新时修订号增加的问题。 修订号可以跳过素数和偶数，仍然可以做它应该做的事情。 轻松实现特定版本。

Answer 9

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

Answer 10

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

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

Answer 11

我在每个存储库中存储一个项目，就像这个颠覆问题的前一个评论者一样，我将共享项目标记为外部项目，因此它们只在源代码控制中执行一次。

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

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

Answer 12

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

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

Answer 13

每个项目一个存储库。

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

Answer 14

@Daniel Fone：SVN文档为每个存储库推荐一个项目，这绝对是创作者想要的方式。 因为你可以让一个服务器（apache或svnserve）维护多个存储库，所以我从来没有遇到过多开销的问题。 使用VisualSVN Server ，安装Apache服务器和配置多个存储库非常容易。

Answer 15

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

Answer 16

修订号没有语义用法。 唯一的问题是，它们是按顺序排列的。 如果转储项目并将其导入另一个存储库，则您的版本可以获得新的修订版号。 因此， 切勿使用修订号来标记您的版本或类似内容。 为发布制作标签（相关修订的副本）。

Answer 17

在我以前的公司遇到同样的问题，他们习惯在一个存储库中运行50个项目，并且在同一个项目上工作是一场噩梦，因为在做svn更新时其他人会诅咒....大声笑......

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