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

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

当我对Ninja程序的主干执行一次提交时，假设我已将其更新到修订版7. 第二天，我对隐身应用程序做了一个小改动，然后又回到了修订版8.

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

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

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

一个或者多个SVN存储库？

解决方案

回答

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

回答

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

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

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

回答

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

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

回答

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

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

同样，如果我们担心设置每个存储库会花费很多时间，请查看Apache配置文件的SVNParentPath变量。 (再次，我假设我们正在使用Apache。)

回答

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

回答

每个项目一个存储库。

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

回答

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

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

回答

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

回答

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

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

回答

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

回答

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

回答

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

我看不出有什么问题，对修订版本号的唯一要求是它是

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

就我而言，每次提交增加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版本控制中对此进行了讨论，该版本可在此处免费在线获得。

我回读了一段时间，确实看起来像是个人选择，这里有一篇不错的博客文章。编辑：由于博客似乎已关闭，(此处为存档版本)，这是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

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

回答

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

回答

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

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