跨多个项目的Subversion修订号

Question

跨多个项目的Subversion修订号

24

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

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

当我提交Ninja Program的主干时，假设我得到它已更新到修订版本7。接下来的一天，假设我对Stealth Application进行了小改动，并且修订号为8。

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

编辑：我推迟标记答案，因为明显存在两种方法的原因，即使这个问题先出现了，我想指向一些最终询问相同问题的其他问题： Should I store all projects in one repository or mulitiple? One SVN Repository or many?

- Kit Roed

17个回答

6

我认为强烈建议为每个项目创建单独的存储库，这样可以避免您所说的情况。版本控制，特别是Subversion，可以轻松地将存储库的部分检出到另一个工作副本中，然后将其提交回各自的存储库。这使您可以保持它们清晰分离并具有很大的灵活性。一旦您更深入地了解SVN（我假设您是新手），您可以开始使用钩子，我可能会看到在您的设置中可能会变得困难。如果权限对您很重要，则单个存储库可能比必要的更加困难。

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

- Barrett Conrad

不，将项目分开放置在不同的代码库中并不常见。将不同的项目放置在同一个代码库中有其优点。但是请不要完全依赖于版本号，因为它们可能会在导出/导入时发生变化。 - Mnementh

4

这是由于svn的工作方式决定的。每个版本实际上是一个由该版本号标识的存储库的快照。如果您的所有项目共享一个存储库，则无法避免这种情况。然而，在我的经验中，通常会为完全不相关的项目设置单独的存储库。所以简短的答案是，不，您没有做错任何事情，这是关于svn的常见问题，但是当您考虑它如何存储存储库信息时，这是有意义的。

- John Downey

4

修订号应该只是特定版本的标识符。它是否按照项目顺序进行排序并不重要。话虽如此，我可以理解这不是最理想的情况。

我遇到的大多数项目都是在单个代码库中设置，并且修订ID以这种方式运作。我不知道任何可以更改此行为的SVN配置选项，并且在我看来，维护多个代码库似乎是一种不必要的开销。

- Daniel Fone

4

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

我认为这没有任何问题-修订号唯一且必须满足以下要求：

- 唯一 - 原子性 - 大于上次checkin时的版本号

对于我来说，它每次提交后增加1或50都无所谓。

@grom:

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

svnadmin create / var / www / svn / myproject

如果您只有1或2个开发人员，我可以看到这样做很好，但是如果创建新项目的人没有shell访问SVN服务器以能够在/var/www下创建目录，会发生什么？

- Orion Edwards

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

- grom

3

嗯，在我工作的地方，我们把所有的项目都放在同一个代码库里。我真的看不出分离它们的好处，那不是会增加很多额外的工作吗——创建新的代码库、授权给人员等等？我想如果这些项目完全不相关，并且你有需要让外部客户访问代码库的情况，分离的代码库可能是有道理的。

- erlendfh

3

在我的工作场所，我们有两个代码库。一个是公开读取的，另一个则包含其他所有内容。我想只使用一个代码库来管理所有内容，但是我们需要为公共和私有项目设置不同的访问权限。

话虽如此，就我个人而言，我并不认为每次更新时递增修订号会带来什么问题。修订号可以跳过素数和偶数，仍然能够达到它应该实现的功能——方便快速获取到特定的修订版本。

- Grant

2

也许最好不是每个“项目”都创建一个仓库，而是每个“解决方案”（使用Visual Studio术语）创建一个仓库。如果您有一堆位于不同文件夹中但相互关联的“项目”，那么请将它们放在同一个仓库中。

- ShaunOfTheLive

2

如果您对基于其他项目更改修订号感到困扰，那么请将这些项目放在单独的存储库中。这是使修订号独立的唯一方法。

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

- crashmstr

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- nemo · Accepted Answer

我惊讶地发现在Subversion版本控制的讨论中，没有人提到这个问题。该书可在线免费获取，链接在这里here。我之前查阅过这个问题，但似乎是个人选择的问题，这个主题有一篇很好的博客文章here。编辑: 由于博客似乎已经关闭，(存档版本在此处)，以下是Mark Phippard在这个问题上的一些观点。

这里是单个仓库方法的一些优势：

简化管理。一个钩子集合部署。一个仓库备份等。

分支/标签灵活性。将代码放在一个仓库中，更容易创建涉及多个项目的分支或标签。

轻松移动代码。也许你想从一个项目中取出一部分代码并在另一个项目中使用，或者将其变成多个项目的库。在同一个仓库中移动代码并在此过程中保留代码历史记录很容易。

这里是单个仓库方法的一些缺点，以及多个仓库方法的优势。

大小。处理许多较小的仓库可能比处理一个大型的仓库更容易。例如，如果您要退出一个项目，只需将仓库归档到介质中并从磁盘中删除它即可释放存储空间。也许您需要转储/加载仓库以利用新的Subversion功能。如果是较小的仓库，则更容易做到这一点，并且影响较小。即使您最终想对所有仓库都这样做，逐个执行会更好，假设没有迫切需要一次执行它们。

全局版本号。虽然这不应该成为问题，但有些人认为这是个问题，不喜欢在存储库中看到版本号不断增加而处于非活跃状态的项目在其版本历史记录中有大的间隔。

访问控制。虽然Subversion的authz机制允许您根据需要限制对存储库部分的访问，但在存储库级别进行此操作更容易。如果您有一个只能由少数几个人访问的项目，那么使用单个存储库更容易实现。

管理灵活性。如果您有多个存储库，则更容易基于存储库/项目的需求实现不同的挂钩脚本。如果想要统一的挂钩脚本，则单个存储库可能更好，但如果每个项目都希望有自己的提交电子邮件样式，则将这些项目放在单独的存储库中更容易。

认真思考后，多项目存储库中的版本号会变得很高，但您不会用完。请记住，您可以查看子目录的历史记录，并快速查看与项目相关的所有修订号。