跨越多个项目的Subversion修订号

Question

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

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

当我执行提交到忍者计划的后备箱，让我们说，我得到的是它已被更新到版本7.第二天让我们说我对隐形应用程序做了一个小改动，并且它作为修订版本8返回。

问题是这样的：当使用一个Subversion服务器维护多个项目时，有无关项目的修订所有项目的数量增加了吗？或者我做错了，应该为每个项目创建单独的存储库？还是完全是另一回事？

编辑：我标记一个答案延迟，因为它已经很清楚，有原因，这两种方法，即使这个问题就来了第一，我想指出的是最终询问一些其他问题同样的问题：

Should I store all projects in one repository or mulitiple?

One SVN Repository or many?

Answer 1

我很惊讶没有提到这是版本控制与颠覆，这是互联网上免费获得here讨论。

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

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

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

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

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

当你真正想一下，多个项目存储库中的版本号会变高，但不会耗尽。请记住，您可以在子目录上查看历史记录，并快速查看与项目相关的所有版本号。

Answer 2

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

Answer 3

我存储每个仓库的一个项目，并喜欢上了这subversion question以前commenter，我大关共享项目外部，使他们只能在源代码控制一次。

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

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

Answer 4

版本号只能是特定版本的标识符。无论项目是否顺序，都不重要。话虽如此，我可以理解它并不理想。

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

Answer 5

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

通过版本控制，尤其是Subversion，您可以轻松地将存储库的各个部分检入另一个工作副本，然后将它们提交回各自的存储库。这可以让你清楚地分开和明确，同时给你很大的灵活性。一旦你进入SVN多一点（我假设你是新的），你可以开始使用钩子，我可能会看到哪里可能会遇到困难，你安装。如果权限对您很重要，则单个存储库可能会比所需的更难。

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

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

一个存储库。

Steven Murawski对CC.NET的评论很有意思。如果你需要指定几个源代码控制仓库，我会很乐意听听它是如何工作的。

Answer 8

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

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

Answer 9

嗯，我工作的地方我们所有的项目都在同一个仓库中。我真的没有看到将它们分开的好处，这不仅仅是创造了许多额外的工作 - 创建新的存储库，准许访问人等等。如果项目完全不相关，那么我认为单独的存储库是有意义的，并且您有需要访问回购的外部客户。

Answer 10

在我的工作场所，我们有两个存储库。一个用于公众阅读，另一个用于其他用途。我只用一个来处理所有事情，但我们需要公共/私人项目的不同访问权限。

这就是说，我个人没有看到每次更新时修订号递增的问题。修订号码可能会跳过总理和偶数，并仍然按照其应该做的事情做。轻松获得特定修订。

Answer 11

@Daniel Fone：SVN文档为每个存储库推荐一个项目，所以这绝对是创作者打算推出的方式。正如你可以让一台服务器（apache或svnserve）维护多个存储库，我从来没有遇到过多的开销问题。使用VisualSVN Server，安装apache服务器并配置多个存储库是一个很好的选择。

Answer 12

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

Answer 13

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

我看不出什么毛病此方法 - 版本号的唯一要求是，它是

• 独特
• 原子
• 大于它是在最后一次签

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

@grom：

然后，每当我开始一个新项目，我就跑：

svnadmin create /var/www/svn/myproject

我可以看到这个工作很好，如果你只得到了1或2但是如果创建新项目的人在SVN服务器上没有shell访问权限以便能够在/ var/www下创建目录，会发生什么情况？

Answer 14

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

Answer 15

在我以前的公司有同样的问题，他们使用有50个项目在一个存储库中运行，这是一个噩梦工作在相同的项目，因为当svn更新其他人会诅咒....大声笑。 ..

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

Answer 16

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

Answer 17

当你真正想一下，在多 项目库中的版本号会得到高，但你不会跑出来 。请记住，您可以在子目录上查看历史记录，并快速查看与项目相关的所有版本号。

实际上，如果你的微软代码编译，并且你使用svn版本号作为你的版本字符串的一部分，那么你可能会用完。如果版本字符串的任何部分大于65535，则Microsoft编译器将引发错误....在我们的情况下，我们有一个68876版本的大型存储库，我们只是碰到了这面墙。