/brz/remove-bazaar

To get this branch, use:
bzr branch http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar

« back to all changes in this revision

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

  • Committer: mernst at mit
  • Date: 2008-10-16 10:57:16 UTC
  • mto: This revision was merged to the branch mainline in revision 3799.
  • Revision ID: mernst@csail.mit.edu-20081016105716-v8x8n5t2pf7f6uds
Improved documentation of stacked and lightweight branches

These patches improve the User Guide's documentation of stacked and
lightweight branches.

Section "1.2.6 Putting the concepts together" should mention stacked
branches and the difference between them and lightweight branches.  It
should also contain links to further details of the common scenarios.

Section "5.3.4 Getting a lightweight checkout" should mention stacked
branches as an option, and should link to all the options, not just some of
them.  It should also clarify that lightweight only applies to checkouts,
not to arbitrary branches.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/en/user-guide/using_gatekeepers.txt
 
1
Using gatekeepers
 
2
=================
 
3
 
 
4
The decentralized with human gatekeeper workflow
 
5
------------------------------------------------
 
6
 
 
7
In this workflow, one developer (the gatekeeper) has commit rights
 
8
to the main branch while other developers have read-only access.
 
9
All developers make their changes in task branches.
 
10
 
 
11
.. image:: images/workflows_gatekeeper.png
 
12
 
 
13
When a developer wants their work merged, they ask the gatekeeper
 
14
to review their change and merge it if acceptable. If a change fails
 
15
review, further development proceeds in the relevant task branch
 
16
until it is good to go.
 
17
 
 
18
Note that a key aspect of this approach is the inversion of control
 
19
that is implied: developers no longer decide when to "commit/push"
 
20
changes into the central branch: the code base evolves by gatekeepers
 
21
"merging/pulling" changes in a controlled manner. It's perfectly
 
22
acceptable, indeed common, to have multiple central branches with
 
23
different gatekeepers, e.g. one branch for the current production
 
24
release and another for the next release. In this case, a task branch
 
25
holding a bug fix will most likely be advertized to both gatekeepers.
 
26
 
 
27
One of the great things about this workflow is that it is hugely
 
28
scalable. Large projects can be broken into teams and each
 
29
team can have a *local master branch* managed by a gatekeeper.
 
30
Someone can be appointed as the primary gatekeeper to merge
 
31
changes from the team master branches into the primary master
 
32
branch when team leaders request it.
 
33
 
 
34
The decentralized with automatic gatekeeper workflow
 
35
----------------------------------------------------
 
36
 
 
37
To obtain even higher quality, all developers can be required to
 
38
submit changes to an automated gatekeeper that only merges and
 
39
commits a change if it passes a regression test suite. One
 
40
such gatekeeper is a software tool called PQM.
 
41
 
 
42
.. image:: images/workflows_pqm.png
 
43
 
 
44
For further information on PQM, see https://launchpad.net/pqm.