关于svn：跨多个项目的Subversion版本号

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

当我对Ninja Program的主干执行一次提交时，假设我已将其更新到修订版7。第二天，我说我对Stealth Application进行了少量更改，然后又回到了修订版8。

问题是：在一个Subversion服务器上维护多个项目时，在所有项目中增加不相关的项目的修订版本号是一种普遍接受的做法吗？还是我做错了，应该为每个项目创建单独的存储库？还是完全其他？

编辑：我延迟标记答案，因为已经很清楚两种方法都有其原因，即使这个问题排在第一位，我也想指出其他一些最终会问相同问题的问题：

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

一个或多个SVN存储库？

我很惊讶没有提到在Subversion版本控制中对此进行了讨论，该版本可在此处免费在线获得。

我回读了一段时间，这似乎是个人选择，这是一篇不错的博客文章。编辑：由于博客似乎已关闭，(此处为存档版本)，这是Mark Phippard不得不说的一些话题。

These are some of the advantages of the single repository approach.

Simplified administration. One set of hooks to deploy. One repository to backup. etc.

Branch/tag flexibility. With the code all in one repository it makes it easier to create a branch or tag involving multiple projects.

Move code easily. Perhaps you want to take a section of code from one project and use it in another, or turn it into a library for several projects. It is easy to move the code within the same repository and retain the history of the code in the process.

Here are some of the drawbacks to the single repository approach, advantages to the multiple repository approach.

Size. It might be easier to deal with many smaller repositories than one large one. For example, if you retire a project you can just archive the repository to media and remove it from the disk and free up the storage. Maybe you need to dump/load a repository for some reason, such as to take advantage of a new Subversion feature. This is easier to do and with less impact if it is a smaller repository. Even if you eventually want to do it to all of your repositories, it will have less impact to do them one at a time, assuming there is not a pressing need to do them all at once.

Global revision number. Even though this should not be an issue, some people perceive it to be one and do not like to see the revision number advance on the repository and for inactive projects to have large gaps in their revision history.

Access control. While Subversion's authz mechanism allows you to restrict access as needed to parts of the repository, it is still easier to do this at the repository level. If you have a project that only a select few individuals should access, this is easier to do with a single repository for that project.

Administrative flexibility. If you have multiple repositories, then it is easier to implement different hook scripts based on the needs of the repository/projects. If you want uniform hook scripts, then a single repository might be better, but if each project wants its own commit email style then it is easier to have those projects in separate repositories

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

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

使用版本控制，尤其是Subversion，您可以轻松地将存储库中的各个部分检出到另一个工作副本中，然后将其提交回各自的存储库中。这样一来，您就可以将它们明确分开和区分，同时还可以提供很大的灵活性。一旦您更多地使用SVN(我假设您是新手)，就可以开始使用钩子，并且我可能会看到在安装时可能会遇到困难。如果许可对您很重要，那么单个存储库可能会证明比必要的困难。

另外，如果您担心要花很多时间来设置每个存储库，请查看Apache配置文件的SVNParentPath变量。 (再次，我假设您正在使用Apache。)

修订号实际上应该仅是特定版本的标识符。是否按顺序进行项目无关紧要。话虽如此，我可以理解这并不理想。

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

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

我看不出有什么问题-版本号的唯一要求是

• 独特
• 原子
• 比上次签到更大

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

@grom：

Then whenever I start a new project I just run:

svnadmin create /var/www/svn/myproject

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

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

在我的工作场所，我们有两个存储库。一种具有公共读取权限，而另一种则具有其他用途。我将只使用一种工具来处理所有事情，但是对于公共/私有项目，我们需要不同的访问权限。

就是说，我个人认为修订号在每次更新时都不会增加。修订号可以跳过素数和偶数，并且仍然可以执行其应做的工作。轻松获得特定版本。

建议对每个项目使用单独的存储库。在我的Apache conf.d目录中，我具有subversion.conf，其中包含：

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

嗯，在我工作的地方，我们所有的项目都在同一个存储库中。我真的看不到将它们分开的好处，难道不只是创建大量额外的工作-创建新的存储库，授予人员访问权限等等？我想如果项目是完全无关的，那么单独的存储库是有意义的，例如，您有需要访问该存储库的外部客户。

如果版本号因其他项目而有所变化，这会使您感到困扰，然后将项目放在单独的存储库中。这是使修订号独立的唯一方法。

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

也许最好不必一定每个"项目"创建一个存储库，而是每个"解决方案"一个存储库(以使用Visual Studio术语)。如果您在不同的文件夹中有一堆"项目"，但它们彼此相关，则将它们放在相同的存储库中。

When you really think about, the revision numbers in a multiple
project repository are going to get high, but you are not going to run
out. Keep in mind that you can view a history on a sub directory and
quickly see all the revision numbers that pertain to a project.

实际上，如果您正在构建Microsoft代码，并且将svn修订号用作版本字符串的一部分，则可能会用完。如果版本字符串的任何部分大于65535，Microsoft编译器都会引发错误。

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

我刚刚开始添加CI构建服务器(CruiseControl.NET)，所以我必须看看所有这些如何工作，但是如果我的构建脚本正确，那应该不是问题。

除了外观外，这实际上是一个偏好问题(我认为)。

我不确定SVN文档实际上建议每个存储库一个项目。通常，他们谈论每条道路的利弊。我碰巧使用了三个不同的存储库，一个用于7或8个相关的项目，这使我很高兴能够仅通过一个修订版本就可以发出所有项目的兼容副本(或者通过查看来验证它们是否兼容)。在每个修订号上)。第二个存储库包含另一组相关的项目和文档，而第三个存储库则小得多。这使我们可以利用以下事实：可以通过单个修订号来管理相关项目，但是不相关的项目不会影响其存储库。

每个项目一个存储库。

史蒂芬·穆拉夫斯基(Steven Murawski)对CC.NET的评论很有趣。如果您需要指定几个源代码控制存储库，我很想听听它是如何工作的。

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

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

我了解到的一件事总是最有效，一个项目One Repo ....您永远不会后悔。

@Daniel Fone：SVN文档为每个存储库推荐一个项目，因此，这绝对是创建者打算使用的方式。由于您可以让一台服务器(apache或svnserve)维护多个存储库，所以我从来没有遇到过多开销的问题。使用VisualSVN Server，安装apache服务器并配置多个存储库非常容易。