Question

我正准备建立一个SVN存储库，并且想知道是否有人为repo结构提供了一个很好的例子。我现在在想：

开发
  ..申请书   .... App1
  ......行李箱   ......分支机构   ......标签
  ..数据库
  ..第三方

虽然这种结构可能包含我们需要的所有东西，但我想让它更加颗粒化。有什么想法吗？

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...

我喜欢完全为第三方提供单独的回购。除非您计划从vendor-branching strategy实施完整的red bean book，否则这将很有效。

Answer 2

我们也一直在努力。

我们发现，在一些共享库是多个应用程序的一部分并且您希望将所有内容都放在同一版本上之前不会花很长时间。因此，我们决定将我们所做的一切都放在一个单一的转发中。我们已经用这种方式工作了两年多，并且发现它非常适合工作。

所有配置都有pro和con，但是通过拥有1个完整的存储库，您可以（几乎）确保在正确的版本中将所有文件放在一起。如果您使用多个主干，那么有虚拟文件夹或链接的技巧（我已经忘记了这个术语）以使其相互链接，但回到原点非常困难。

请记住每个配置都有pro和con，但是对于一个不大的公司，我建议将所有内容放在一个包含一个父文件夹的repo中。

Answer 3

我目前的方法是在一个存储库下打破逻辑应用程序边界上的系统。

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

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

这允许我们有多个与项目相关联的应用程序，但处理每个“逻辑”应用程序边界的释放控制。考虑您的版本控制需要的位置和内容，并将其设置为分支/标记/主干结构的位置。

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

Answer 4

SVN提供标签以在特定时间（可用于发布等）获取源树的“及时快照”。

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

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

Answer 5

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

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

Answer 6

拥有一个单独的仓库意味着你很有可能以极快的速度结束一个巨大的存储库。这意味着事情变得缓慢而且有点难以追踪。显然，这取决于您的确切用例，但我个人会选择每个项目的存储库并在需要时使用svn：externals。

实际上，如果可能的话，我会选择通过SVN分发VCS，但是他自己选择...

SVN存储库结构

6 个答案: