私たちは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 のベスト プラクティス - チームでの作業