~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

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

  • Committer: Ian Clatworthy
  • Date: 2007-11-14 03:50:56 UTC
  • mto: (3054.1.1 ianc-integration)
  • mto: This revision was merged to the branch mainline in revision 3055.
  • Revision ID: ian.clatworthy@internode.on.net-20071114035056-72l6odzpby4bcmub
First cut at new look User Guide including chapters 1 and 2

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
Bazaar workflows
 
2
================
 
3
 
 
4
Bazaar is just a tool
 
5
---------------------
 
6
 
 
7
One of the best things about Bazaar is that it supports many
 
8
different ways of working together. This means that you can
 
9
start with one workflow and adapt it over time as circumstances
 
10
change. There is no "one true way" that always makes sense and
 
11
there never will be. The section provides a brief overview of
 
12
some popular workflows supported by Bazaar.
 
13
 
 
14
 
 
15
Solo
 
16
----
 
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.
 
19
 
 
20
.. image:: images/workflows_single.png
 
21
 
 
22
Advantages over not using version control at all:
 
23
 
 
24
 * backup of old versions
 
25
 * rollback to an earlier state
 
26
 * tracking of history.
 
27
 
 
28
The key features of Bazaar appropriate for this workflow are low administration (no server setup) and ease of use.
 
29
 
 
30
 
 
31
Partner
 
32
-------
 
33
 
 
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 is parallel exchanging changes by merging when appropriate.
 
35
 
 
36
.. image:: images/workflows_peer.png
 
37
 
 
38
Advantages over *Solo* are:
 
39
 
 
40
 * 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.
 
42
 
 
43
When implementing this workflow, Bazaar's advantages over CVS and Subversion include:
 
44
 
 
45
 * no server to setup
 
46
 * intelligent merging means merging multiple times isn't painful.
 
47
 
 
48
 
 
49
Centralized
 
50
-----------
 
51
 
 
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 commit.
 
53
 
 
54
.. image:: images/workflows_centralized.png
 
55
 
 
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:
 
57
 
 
58
 * much better branching and merging
 
59
 * better renaming support.
 
60
 
 
61
 
 
62
Centralized with local commits
 
63
------------------------------
 
64
 
 
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, then commit their work to the shared mainline when it is complete.
 
66
 
 
67
.. image:: images/workflows_localcommit.png
 
68
 
 
69
Advantages over *Centralized*:
 
70
 
 
71
 * Can work offline, e.g. when disconnected during travel
 
72
 * Less chance for a bad commit to interfere with everyone else's work
 
73
 
 
74
Subversion and CVS do not support this model. Other distributed VCS tools can support it but do so less directly than Bazaar does.
 
75
 
 
76
 
 
77
Decentralized with shared mainline
 
78
----------------------------------
 
79
 
 
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.
 
81
 
 
82
.. image:: images/workflows_shared.png
 
83
 
 
84
Advantage over *Centralized with local commits*:
 
85
 
 
86
 * Easier organization of work - separate changes can be developed in their own branches
 
87
 * Developers can merge one another's personal branches when working on something together
 
88
 
 
89
Subversion and CVS do not support this model. Other distributed VCS tools support it. When selecting a DVCS tool for this workflow, look for ease of use, high quality merging, good renaming support and efficient storage (e.g. shared repositories), all of which are strengths of Bazaar.
 
90
 
 
91
 
 
92
Decentralized with human gatekeeper
 
93
-----------------------------------
 
94
 
 
95
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.
 
96
 
 
97
.. image:: images/workflows_gatekeeper.png
 
98
 
 
99
Advantage over *Decentralized with shared mainline*:
 
100
 
 
101
 * Code is always reviewed before it enters the mainline.
 
102
 
 
103
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. Subversion and CVS do not support this model. Other distributed VCS tools can support it. When selecting a DVCS tool for this workflow, once again look for ease of use, high quality merging, good renaming support and efficient storage.
 
104
 
 
105
 
 
106
Decentralized with automatic gatekeeper
 
107
---------------------------------------
 
108
 
 
109
In this workflow, each developer has their own branch or branches, plus read-only access to the mainline. A software gatekeeper (e.g. PQM) has commit rights to the main branch. When a developer wants their work merged, they request another person to review it. Once passed review, either the original author or the reviewer asks the gatekeeper to merge it, depending on team policies. The gatekeeper does a merge, a compile, and runs the test suite. If the code passes, it is merged into the mainline.
 
110
 
 
111
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.)
 
112
 
 
113
.. image:: images/workflows_pqm.png
 
114
 
 
115
Advantages over *Decentralized with human gatekeeper*:
 
116
 
 
117
 * Code is always tested before it enters the mainline (so the integrity of the mainline is higher)
 
118
 * Scales better as teams grow.
 
119
 
 
120
A companion tool of Bazaar's called Patch Queue Manager (PQM) can provide the automated gatekeeper capability. Otherwise, the comments on tool selection given for *Decentralized with human gatekeeper* apply here as well.
 
121
 
 
122
 
 
123
Implementing a workflow
 
124
-----------------------
 
125
 
 
126
For an in depth look at how to implement each of the workflows above,
 
127
see chapters 3 and beyond in this manual. First though, chapter 2
 
128
explains some important pre-requisites including installation, general
 
129
usage instructions and configuration tips.