logo标签列表

SVN仓库结构

svnrepositoryrepository-design
6

我正准备建立一个SVN仓库，想知道是否有一个好的仓库结构示例。我目前的想法是：

开发
.. 应用程序
.... 应用程序1
...... 主干
...... 分支
...... 标签
.. 数据库
.. 第三方

虽然这个结构可能可以容纳我们需要的一切，但我想让它更加精细化。 有什么想法吗？

“a bit more granulated”是什么意思？ - Marc W
细化 - 变得粒状或颗粒状。- 免费在线词典。我认为他的意思是他想进一步完善这个结构。 - mauris
不了解他/她创建仓库的系统要求，我们无法真正提供帮助。 - Marc W
6个回答
11

我们最初采用了类似的模型，但发现它有些繁琐。 主要问题是，如果您想在发布时为代码库创建分支，您必须为每个组件创建分支。

相反，我们考虑了以下方案：

  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中实现完整的供应商分支策略，否则这种方法会很有效。

2

我们也曾经苦于此。

我们发现，一些共享库很快就会成为多个应用程序的一部分，您会希望所有内容都在同一个版本中。因此，我们决定将我们所做的一切放在一个单独的代码库中。我们已经这样工作了两年多，发现非常好用。

所有配置都有优点和缺点，但是通过拥有一个完整的代码库，您可以（几乎）确定您拥有的所有文件都是正确的版本。如果您使用多个主干，则可以使用虚拟文件夹或链接（我忘记了术语）进行链接，但是回到之前的点很难。

请记住，每种配置都有优缺点，但对于不是太大的公司，我建议将所有内容都放在一个具有一个父文件夹的单独代码库中。

1

我的当前方法是在一个代码库下，按照逻辑应用边界来分割系统。

例如，想象一下一个服务，它还有一个测试套件和一个数据库。

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

这使我们能够将多个应用程序与一个项目相关联，但处理每个“逻辑”应用程序边界的发布控制。考虑您的发布控制需求所在的位置/内容，并将其设置为分支/标记/主干结构的位置。

我不喜欢整个存储库根目录下的单个主干/分支/标记文件夹，因为我不想检出整个主干，也不想因此而搞乱部分分支检出。（您可能持不同意见，您的情况可能有所不同等等）

0

SVN 提供标签来在特定时间点对源代码树进行“时间快照”（您可以用于发布等）。

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

当然，在“主干”文件夹中，您应该设置任何正常的目录层次结构，就像您没有使用源代码控制一样。

0
我们总是为每个独立的“解决方案”创建一个单独的SVN存储库。然后，该存储库只有一个简单的主干、分支和标签结构。
任何依赖框架（我们控制源代码的地方）都有自己独立的存储库。通常，我们只会将二进制文件（特定版本）包含到使用它们的任何项目中。
0

将所有内容放在一个仓库中意味着您很有可能很快就会拥有一个巨大的仓库。这意味着事情可能会变得缓慢和有点难以跟踪。显然，这取决于您的确切用例，但个人而言，我会选择每个项目的仓库，并在需要时使用svn:externals。

实际上，如果可能的话，我会选择分布式版本控制系统而不是SVN，但各有所好...

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接