SVN存储库结构

Question

我准备建立一个SVN仓库，并想知道是否有人有一个很好的回购结构的例子。我目前想：

发展
..应用
....应用1
......躯干
......分行
......标签
..数据库
..第三方

虽然这种结构很可能保持我们需要的一切，我想作它有点颗粒化。有什么想法吗？

Answer 1

我们从一个类似的模型开始，但发现它有点麻烦。主要的问题是，如果你想在一个版本中分支你的代码库，你必须为每个组件分支。

取而代之的是，我们已经考虑像下面这样的方案：

trunk 
    app1 
    app2 
    lib1 
    lib2 
    branches 
    rc-2.0 
     app1, app2, lib1, lib2... 
    some-devs-branch 
     app1, lib2 
    tags 
    release-1.0 
     app1, app2, lib1, lib2... 

我喜欢有一个单独的回购完全由第三方的东西。除非您计划执行red bean book中的完整vendor-branching strategy，否则这将运行良好。

Answer 2

SVN提供标签以在特定时间（您可以用于版本等）在源树中“拍摄快照”。

但是，如果您打算让您的存储库更“粒化”，也许您应该考虑设置多个存储库。

当然，在'trunk'文件夹中，如果你没有使用源代码控制，你应该设置任何正常的目录层次结构。

Answer 3

我们也一直在努力。

我们发现它不需要很长时间，直到某些共享库是多个应用程序的一部分，并且您希望在同一版本上拥有所有内容。因此，我们决定将我们所做的一切都放在一个单一的替代品中。我们已经以这种方式工作了2年多，并发现与它合作非常好。

所有的配置都有pro和con的配置，但是通过拥有1个完整的存储库，您可以（几乎）确定所有文件都以正确的版本组合在一起。如果你使用多个主干，那么虚拟文件夹或链接（我已经忘记了这个术语）会让它与对方链接，但回到你所在的位置非常困难。

只记得每个配置都有pro和con的，但对于一个不大的公司，我建议把所有东西放在一个父文件夹的单个回购中。

Answer 4

我目前的做法是将逻辑应用程序边界上的系统全部置于一个存储库下。

例如，假设也有一个测试套件服务和数据库

/project1/application1/ 
         trunk/ 
          Src 
          Test 
          Database 
         tags/ 
         branches/ 
     application2/ 
         trunk/ 
          Src 
          Test 
         tags/ 
         branches/      

这让我们有一个项目assoicated多个应用程序，但手柄释放控制每个“逻辑”的应用边界。考虑你的版本控制需要在哪里/什么，并将它们设置为分支/标记/中继结构的位置。

我不喜欢整个存储库根目录下的单个trunk/branches/tags文件夹，因为我不希望检出整个主干，也不想将部分分支签出混淆为结果。 （你可能会不同意，你的里程可能会有所不同，等等）

Answer 5

我们总是为每个单独的“解决方案”创建一个单独的SVN存储库。这个存储库只有一个简单的主干，分支和标签结构。

任何依赖框架（我们控制源代码）都有自己的独立存储库。然后，我们通常会将二进制文件（特定版本）包含到使用它们的任何项目中。

Answer 6

对于一切都有一个单一的回购意味着你有一个非常好的机会以极快的速度结束一个巨大的仓库。这意味着事情会变得缓慢并且难以跟踪。显然，这取决于你的确切用例，但是我个人会选择每个项目的存储库，并在需要时使用svn：externals。

事实上，我会选择超过SVN如果可能的话一个分布式VCS，但每一个他自己......