Question

我们正在开发一个java项目并且每天都有自动构建，并且大多数时候我们都会检查我们的代码，即使它不完整只是为了保存它，很多时候由于一个人而导致构建中断（不是由于错误，只是他的代码不完整）。

为了避免这种情况，SVN中有任何选项可以指定构建版本/标记，以便从此版本中获取文件，即已完成代码的人员将其构建版本作为最新版本，并且拥有不完整的代码签入会将他们的构建版本指向早期版本，以免破坏构建。

Answer 1

Subversion best practices doc中解释的分支 - 可能是最好的方法。

The Branch-When-Needed system
    Users commit their day-to-day work on /trunk.
    Rule #1: /trunk must compile and pass regression tests at all times. Committers who violate this rule are publically humiliated.
    Rule #2: a single commit (changeset) must not be so large so as to discourage peer-review.
    Rule #3: if rules #1 and #2 come into conflict (i.e. it's impossible to make a series of small commits without disrupting the trunk), then the user should create a branch and commit a series of smaller changesets there. This allows peer-review without disrupting the stability of /trunk.

Pros: /trunk is guaranteed to be stable at all times. The hassle of branching/merging is somewhat rare.
Cons: Adds a bit of burden to users' daily work: they must compile and test before every commit.

使用svn copy (cp)创建分支来管理非平凡的更改。

svn copy <base url or path>/trunk <base url or path>/branches/enhancement-1

然后将与这些更改相关的更改提交到分支，但不提交到主干合并从主干到这些分支的定期更改，以便不会从主干中过时分支。

cd branch-dir
svn merge -r <rev1>:<rev2> <base url or path>/trunk
svn ci

当分支的变化足够稳定时，将它们合并回主干。

cd trunk-dir
svn merge -r <revX>:<revY> <base url or path>/branches/enhancement-1
svn ci

跟踪重要的修订号（rev1，rev2，revX，revY等）将比通过svn log更容易。

示例存储库布局。

project/
├── branches
│   ├── major-refactoring-1     <= specific changes on a refactoring that can not be moved to trunk yet
│   ├── production              <= most of the time changes from trunk will be merged into this for production releases
│   ├── user-1                  <= certain changes done by a user not stable enough to move to trunk
│   └── user-2
├── tags
└── trunk

其他指南：
http://mazamascience.com/WorkingWithData/?p=623
SVN best-practices - working in a team

SVN构建版本

1 个答案: