« back to all changes in this revision
Viewing changes to doc/en/user-guide/bazaar_workflows.txt
- browse files at revision 3240
- compare with another revision
- download diff
- download tarball
- view history from revision 3240
- Committer: Canonical.com Patch Queue Manager
- Date: 2008-02-27 21:31:54 UTC
- mfrom: (3237.1.2 jam-integration)
- Revision ID: pqm@pqm.ubuntu.com-20080227213154-a7egrkiapeuvmu3b
(jam) wrap bazaar_workflows.txt to 79 chars
- files modified:
- doc/en/user-guide/bazaar_workflows.txt
added
removed
doc/en/user-guide/bazaar_workflows.txt
15
15
Solo
16
16
----
17
17
18
Whether developing software, editing documents or changing configuration files, having an easy-to-use VCS tool can help. A single user can use this workflow effectively for managing projects where they are the only contributor.
18
Whether developing software, editing documents or changing configuration files,
19
having an easy-to-use VCS tool can help. A single user can use this workflow
20
effectively for managing projects where they are the only contributor.
19
21
20
22
.. image:: images/workflows_single.png
21
23
25
27
* rollback to an earlier state
26
28
* tracking of history.
27
29
28
The key features of Bazaar appropriate for this workflow are low administration (no server setup) and ease of use.
30
The key features of Bazaar appropriate for this workflow are low administration
31
(no server setup) and ease of use.
29
32
30
33
31
34
Partner
32
35
-------
33
36
34
Sometimes two people need to work together sharing changes as they go. This commonly starts off as a *Solo* workflow (see above) or a team-oriented workflow (see below). At some point, the second person takes a branch (copy including history) of what the first person has done. They can then work in parallel exchanging changes by merging when appropriate.
37
Sometimes two people need to work together sharing changes as they go. This
38
commonly starts off as a *Solo* workflow (see above) or a team-oriented
39
workflow (see below). At some point, the second person takes a branch (copy
40
including history) of what the first person has done. They can then work in
41
parallel exchanging changes by merging when appropriate.
35
42
36
43
.. image:: images/workflows_peer.png
37
44
38
45
Advantages over *Solo* are:
39
46
40
47
* easier sharing of changes
41
* each line of each text file can be attributed to a particular change including who changed it, when and why.
48
* each line of each text file can be attributed to a particular change
49
including who changed it, when and why.
42
50
43
51
When implementing this workflow, Bazaar's advantages over CVS and Subversion include:
44
52
49
57
Centralized
50
58
-----------
51
59
52
Also known as *lock-step*, this is essentially the same as the workflow encouraged/enforced by CVS and Subversion. All developers work on the same branch (or branches). They run ``bzr update`` to get their checkout up-to-date, then ``bzr commit`` to publish their changes to the central location.
60
Also known as *lock-step*, this is essentially the same as the workflow
61
encouraged/enforced by CVS and Subversion. All developers work on the same
62
branch (or branches). They run ``bzr update`` to get their checkout up-to-date,
63
then ``bzr commit`` to publish their changes to the central location.
53
64
54
65
.. image:: images/workflows_centralized.png
55
66
56
Subversion and CVS are good choices for implementing this workflow because they make it easy. Unlike the vast majority of distributed VCS tools, Bazaar makes it easy as well by directly supporting it. In addition, Bazaar provides some important advantages over CVS and Subversion:
67
Subversion and CVS are good choices for implementing this workflow because they
68
make it easy. Unlike the vast majority of distributed VCS tools, Bazaar makes
69
it easy as well by directly supporting it. In addition, Bazaar provides some
70
important advantages over CVS and Subversion:
57
71
58
72
* better branching and merging
59
73
* better renaming support.
62
76
Centralized with local commits
63
77
------------------------------
64
78
65
This is essentially the same as the *Centralized* model, except that when developers are making a series of changes, they do ``commit --local`` or unbind their checkout. When it is complete, they commit their work to the shared mainline.
79
This is essentially the same as the *Centralized* model, except that when
80
developers are making a series of changes, they do ``commit --local`` or unbind
81
their checkout. When it is complete, they commit their work to the shared
82
mainline.
66
83
67
84
.. image:: images/workflows_localcommit.png
68
85
71
88
* Can work offline, e.g. when disconnected during travel
72
89
* Less chance for a bad commit to interfere with everyone else's work
73
90
74
Subversion and CVS do not support this model. Other distributed VCS tools can support it but do so less directly than Bazaar does.
91
Subversion and CVS do not support this model. Other distributed VCS tools can
92
support it but do so less directly than Bazaar does.
75
93
76
94
77
95
Decentralized with shared mainline
78
96
----------------------------------
79
97
80
In this workflow, each developer has their own branch or branches, plus commit rights to the main branch. They do their work in their personal branch, then merge it into the mainline when it is ready.
98
In this workflow, each developer has their own branch or branches, plus commit
99
rights to the main branch. They do their work in their personal branch, then
100
merge it into the mainline when it is ready.
81
101
82
102
.. image:: images/workflows_shared.png
83
103
95
115
Decentralized with human gatekeeper
96
116
-----------------------------------
97
117
98
In this workflow, each developer has their own branch or branches, plus read-only access to the main branch. One developer (the gatekeeper) has commit rights to the main branch. When a developer wants their work merged, they ask the gatekeeper to merge it. The gatekeeper does code review, and merges the work into the main branch if it meets the necessary standards.
118
In this workflow, each developer has their own branch or branches, plus
119
read-only access to the main branch. One developer (the gatekeeper) has commit
120
rights to the main branch. When a developer wants their work merged, they ask
121
the gatekeeper to merge it. The gatekeeper does code review, and merges the
122
work into the main branch if it meets the necessary standards.
99
123
100
124
.. image:: images/workflows_gatekeeper.png
101
125
104
128
* Code is always reviewed before it enters the mainline
105
129
* Tighter control over when changes get incorporated into the mainline.
106
130
107
A companion tool of Bazaar's called Bundle Buggy can be very useful for tracking what changes are up for review, their status and reviewer comments.
131
A companion tool of Bazaar's called Bundle Buggy can be very useful for
132
tracking what changes are up for review, their status and reviewer comments.
108
133
109
134
110
135
Decentralized with automatic gatekeeper
111
136
---------------------------------------
112
137
113
In this workflow, each developer has their own branch or branches, plus read-only access to the mainline. A software gatekeeper has commit rights to the main branch. When a developer wants their work merged, they request another person to review it. Once it has passed review, either the original author or the reviewer asks the gatekeeper software to merge it, depending on team policies. The gatekeeper software does a merge, a compile, and runs the test suite. If and only if the code passes, it is merged into the
114
mainline.
138
In this workflow, each developer has their own branch or branches, plus
139
read-only access to the mainline. A software gatekeeper has commit rights to
140
the main branch. When a developer wants their work merged, they request another
141
person to review it. Once it has passed review, either the original author or
142
the reviewer asks the gatekeeper software to merge it, depending on team
143
policies. The gatekeeper software does a merge, a compile, and runs the test
144
suite. If and only if the code passes, it is merged into the mainline.
115
145
116
Note: As an alternative, the review step can be skipped and the author can submit the change to the automatic gatekeeper without it. (This is particularly appropriate when using practices such as Pair Programming that effectively promote just-in-time reviews instead of reviewing code as a separate step.)
146
Note: As an alternative, the review step can be skipped and the author can
147
submit the change to the automatic gatekeeper without it. (This is particularly
148
appropriate when using practices such as Pair Programming that effectively
149
promote just-in-time reviews instead of reviewing code as a separate step.)
117
150
118
151
.. image:: images/workflows_pqm.png
119
152
120
153
Advantages over *Decentralized with human gatekeeper*:
121
154
122
* Code is always tested before it enters the mainline (so the integrity of the mainline is higher)
155
* Code is always tested before it enters the mainline (so the integrity of the
156
mainline is higher)
123
157
* Scales better as teams grow.
124
158
125
A companion tool of Bazaar's called Patch Queue Manager (PQM) can provide the automated gatekeeper capability.
159
A companion tool of Bazaar's called Patch Queue Manager (PQM) can provide the
160
automated gatekeeper capability.
126
161
127
162
128
163
Implementing a workflow
Loggerhead is a web-based interface for Breezy
Version: 2.0.1