版本控制中的项目结构

问题描述：

我知道在版本控制中至少有10种不同的方式来构造项目。我很好奇正在使用的某些方法以及哪种方法对您有用。我曾经使用SVN，TFS和当前/不幸的是VSS。我见过版本控制的执行效果很差，虽然还可以，但是从来都不是很好。

I know there are at least 10 different ways to structure project in version control. I'm curious what some methods being used are and which ones work for you. I've worked with SVN, TFS, and currently/unfortunately VSS. I've seen version control implemented very poorly and just OK, but never great.

只是让事情滚滚而来，这里是对我所见过的事情的回顾。

Just to get the ball rolling, here is a review of things I've seen.

该示例基于SVN，但适用于大多数VCS（不适用于分布式版本控制）。

This example is SVN-based, but applies to most VCS's (not so much to distributed version control).

分支属于站点
/ division / web / projectName / vb / src / [trunk | Branches | tags]

branch the individual projects that are part of site /division/web/projectName/vb/src/[trunk|branches|tags]

分支整个站点，在我所看到的情况下，除了核心组件之外的整个站点都是分支的。
/ division / [trunk | branch | tags] / web / projectName / vb / src /

branch the whole site, in the case I've seen, the whole site except for core components was branched. /division/[trunk|branches|tags]/web/projectName/vb/src/

使用主线是默认的，只有分支巨大更改所必需的。

Use main-line a default, only branch when necessary for huge changes.

答

我们使用Java进行高度组件化的开发，我们的主干中有大约250个具有独立生命周期的模块。依赖关系是通过Maven管理的（这是目前的最佳做法），每次（每两周一次）主动开发的模块都会使用新版本进行标记。具有严格语义的3位版本号（major.minor.build-重大更改表示向后不兼容，较小更改表示向后兼容，而内部版本号更改表示向后和向前兼容）。我们最终的软件产品是一个程序集，该程序集可以引入数十个单独的模块，再次作为Maven依赖项。

We practice highly componentised development using Java, we have about 250 modules in trunk that have independent life cycles. Dependencies are managed through Maven (that's a best practice right there), every iteration (bi-weekly) actively developed modules get tagged with a new version. 3 digit version numbers with strict semantics (major.minor.build - major changes means backwards incompatible, minor changes mean backwards compatible and build number changes mean backwards and forwards compatible). Our ultimate software product is an assembly that pulls in dozens of individual modules, again as Maven dependencies.

当需要进行错误修复或增强时，我们会分支模块/程序集。对于已发布的版本，我们无法提供HEAD版本。标记所有版本使此操作变得容易，但是分支仍然会产生相当大的管理开销（特别是使分支与某些HEAD变更集保持同步），这部分是由我们的工具引起的，Subversion对于管理分支而言不是最优的。

We branch modules/assemblies when we need to make a bug fix or enhancement for a released version and we can not deliver the HEAD version. Having tagged all versions makes this easy to do but branches still incur a significant administrative overhead (specifically keeping branches in sync with certain HEAD changesets) that are partly caused by our tools, Subversion is sub-optimal for managing branches.

我们发现，存储库中相当平坦且最重要的可预测树结构至关重要。它使我们能够构建发布工具，从而消除了手动发布过程中的许多痛苦和危险（更新的发布说明，项目编译，运行的单元测试，进行了标记，没有SNAPSHOT依赖项等）。避免在树形结构中添加过多的分类或其他逻辑。

We find that a fairly flat and above all predictable tree structure in the repository is crucial. It has allowed us to build release tools that take away a lot of the pain and danger from a manual release process (updated release notes, project compiles, unit tests run through, tag is made, no SNAPSHOT dependencies, etc). Avoid putting too much categorization or other logic in your tree structure.

我们大致执行以下操作：

We roughly do something like the following:

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之类的东西：将依赖项作为对版本库中唯一标识的二进制工件的引用进行管理。

For external dependencies, I can not overemphasize something like Maven: manage your dependencies as references to versioned, uniquely identified binary artifacts in a repository.

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

For intenal module/project structure: stick to a standard. Uniformity is key. Again, Maven can help here since it dictates a structure. Many structures are fine, as long as you stick to them.

版本控制中的项目结构

相关推荐