我们正在开发一个java项目并且每天都有一个自动构建,大多数时候我们会检查我们的代码,即使它不完整只是为了保存它,很多时候构建由于一个人而中断(不是由于出错,只是他的代码不完整)。
为了避免这种情况,我可以在 SVN 中分配一个构建修订版/标签,以便从该修订版中获取文件,即完成代码的人将他们的构建修订版作为最新修订版,而代码签入不完整的人会将他们的构建版本指向较早的版本,以免破坏构建。
我们正在开发一个java项目并且每天都有一个自动构建,大多数时候我们会检查我们的代码,即使它不完整只是为了保存它,很多时候构建由于一个人而中断(不是由于出错,只是他的代码不完整)。
为了避免这种情况,我可以在 SVN 中分配一个构建修订版/标签,以便从该修订版中获取文件,即完成代码的人将他们的构建修订版作为最新修订版,而代码签入不完整的人会将他们的构建版本指向较早的版本,以免破坏构建。
如Subversion 最佳实践文档中所述,按需分支可能是最好的方法。
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 最佳实践 - 团队合作