SVN build revision

Question

我們正在開發一個java項目，並且每天都有一個自動構建，並且大部分時間我們都會檢查我們的代碼，即使它不完整隻是爲了保存它，很多次構建因爲一個人（不是由於錯誤，只是他的代碼不完整）。

爲了避免這種情況，SVN中有任何選項可以指定構建版本/標記，以便它從此版本獲取文件，即完成代碼的人員將構建版本作爲最新修訂版本，有不完整的代碼checkin會將其構建版本指向較早的版本，以免破壞構建。

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，轉2，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