svn - 版本控制中的项目结构

Question

我知道在版本控制中至少有 10 种不同的方式来构建项目。我很好奇正在使用哪些方法以及哪些方法适合您。我曾使用过 SVN、TFS 和目前/不幸的是 VSS。我已经看到版本控制实现得非常糟糕而且还不错，但从来都不是很好。

只是为了让球滚动，这里是我所看到的事情的回顾。

这个例子是基于 SVN 的，但适用于大多数 VCS(对分布式版本控制不太适用)。

分支作为站点一部分的单个项目
/division/web/projectName/vb/src/[主干|分支|标签]

分支整个站点，在我看到的情况下，除了核心组件之外的整个站点都被分支了。
/division/[主干|分支|标签]/web/projectName/vb/src/

使用主线作为默认值，仅在必要时分支 巨大的变化。

Answer 1

我们使用 Java 进行高度组件化的开发，我们在主干中有大约 250 个具有独立生命周期的模块。依赖项是通过 Maven 管理的(这是一个最佳实践)，每次迭代(每两周一次)积极开发的模块都会被标记为新版本。具有严格语义的 3 位版本号(major.minor.build - 主要更改意味着向后不兼容，次要更改意味着向后兼容，内部版本号更改意味着向后和向前兼容)。我们最终的软件产品是一个包含数十个单独模块的程序集，同样作为 Maven 依赖项。

当我们需要对已发布版本进行错误修复或增强并且我们无法交付 HEAD 版本时，我们会分支模块/程序集。标记所有版本使这很容易做到，但是分支仍然会产生大量的管理开销(特别是使分支与某些 HEAD 变更集保持同步)，这部分是由我们的工具引起的，Subversion 对于管理分支不是最佳的。

我们发现一个相当平坦的，最重要的是可预测的存储库中的树结构至关重要。它使我们能够构建发布工具，从而消除手动发布过程中的许多痛苦和危险(更新的发布说明、项目编译、运行单元测试、制作标签、无 SNAPSHOT 依赖项等)。避免在树形结构中放置过多的分类或其他逻辑。

我们大致做如下的事情:

svnrepo/
  trunk/
    modules/
      m1/ --> will result in jar file
      m2/
      ...
    assemblies/
      a1/
      ...
  tags/
    modules/
      m1/
        1.0.0/
        1.0.1/
        1.1.0/
       m2/
      ...
    assemblies/
      a1/
        iteration-55/
        ...
  branches/
    m1/
      1.0/
      ...

对于外部依赖项，我不能过分强调 Maven 之类的东西:将依赖项管理为对存储库中版本化、唯一标识的二进制工件的引用。

对于内部模块/项目结构:坚持标准。一致性是关键。同样，Maven 在这里可以提供帮助，因为它规定了一个结构。许多结构都很好，只要你坚持下去。