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