← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/ja/user-guide/using_gatekeepers.txt

  • Committer: John Arbash Meinel
  • Date: 2009-03-04 21:22:50 UTC
  • mto: (0.17.34 trunk)
  • mto: This revision was merged to the branch mainline in revision 4280.
  • Revision ID: john@arbash-meinel.com-20090304212250-xcvwt1yx4zt76pev
Have the GroupCompressBlock decide how to compress the header and content.
It can now decide whether they should be compressed together or not.
As long as we make the to_bytes() function match the from_bytes() one, we should be fine.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/ja/user-guide/using_gatekeepers.txt
1
 
ゲートキーパーを利用する
2
 
=========================
3
 
 
4
 
分散型の人間のゲートキーパーのワークフロー
5
 
-------------------------------------------
6
 
 
7
 
このワークフローでは、1人の開発者(ゲートキーパー) がメインブランチへの\
8
 
コミット権限を持つ一方で他の開発者はリードオンリーの権限のみを持ちます。
9
 
すべての開発者はタスクブランチの中で変更を行います。
10
 
 
11
 
.. image:: images/workflows_gatekeeper.png
12
 
 
13
 
開発者は彼らの作業内容をマージしたいとき、ゲートキーパーに彼らの変更を\
14
 
レビューして受け入れ可能であればマージするよう頼みます。
15
 
変更がレビューを失敗するとき、準備ができるまで関連のタスクブランチで\
16
 
さらなる開発が進みます。
17
 
 
18
 
このアプローチの主要な面は含まれる制御の反転です:
19
 
開発者は変更を中心ブランチに"コミット/プッシュ"するときを決めなくて済みます:
20
 
コードベースはゲートキーパーの "マージ/プル" による統制された変更方法によって発展します。
21
 
複数の中心ブランチとそれぞれ異なるゲートキーパーをを持つことはとてもよい方法で、
22
 
よく採用されている方法です。。
23
 
たとえば、現在の製品リリースと次のリリースのためにそれぞれ1つづつのブランチがあります。
24
 
この場合、たいがいはバグ修正を保持するタスクブランチは両方のゲートキーパーによって\
25
 
通知されます。
26
 
 
27
 
このワークフローのすばらしい点の一つはスケーラブルであることです。
28
 
大きなプロジェクトはチームになりそれぞれのチームはゲートキーパーによって管理される
29
 
*ローカルマスターブランチ* を持つことができます。
30
 
チームリーダーがリクエストするときにチームのマスターブランチからの変更を\
31
 
プライマリマスターブランチにマージするために誰かを主席ゲートキーパーに任命できます。
32
 
 
33
 
分散型の自動ゲートキーパーのワークフロー
34
 
-----------------------------------------
35
 
 
36
 
より高い品質を得るために、すべての開発者は変更を回帰テストスイートが通ったら\
37
 
変更のマージとコミットだけを行う自動ゲートキーパーに投稿できることが求められます。
38
 
このようなゲートキーパーの1つはPQMと呼ばれるソフトウェアツールです。
39
 
 
40
 
.. image:: images/workflows_pqm.png
41
 
 
42
 
PQMに関する詳細な情報に関しては、 https://launchpad.net/pqm を参照してください。