Rev 3240: (jam) wrap bazaar_workflows.txt to 79 chars in file:///home/pqm/archives/thelove/bzr/%2Btrunk/

Canonical.com Patch Queue Manager pqm at pqm.ubuntu.com
Wed Feb 27 21:32:01 GMT 2008


At file:///home/pqm/archives/thelove/bzr/%2Btrunk/

------------------------------------------------------------
revno: 3240
revision-id:pqm at pqm.ubuntu.com-20080227213154-a7egrkiapeuvmu3b
parent: pqm at pqm.ubuntu.com-20080227195331-0nc0vzgjka1ornoe
parent: john at arbash-meinel.com-20080227164153-gtx6hncy32u8oa2v
committer: Canonical.com Patch Queue Manager <pqm at pqm.ubuntu.com>
branch nick: +trunk
timestamp: Wed 2008-02-27 21:31:54 +0000
message:
  (jam) wrap bazaar_workflows.txt to 79 chars
modified:
  doc/en/user-guide/bazaar_workflows.txt bazaar_workflows.txt-20071114035000-q36a9h57ps06uvnl-1
    ------------------------------------------------------------
    revno: 3237.1.2
    revision-id:john at arbash-meinel.com-20080227164153-gtx6hncy32u8oa2v
    parent: john at arbash-meinel.com-20080227161929-vpcyxi0v7ei24sqg
    committer: John Arbash Meinel <john at arbash-meinel.com>
    branch nick: jam-integration
    timestamp: Wed 2008-02-27 10:41:53 -0600
    message:
      wrap doc/en/user-guide/bazaar_workflows.txt for 79 characters
    modified:
      doc/en/user-guide/bazaar_workflows.txt bazaar_workflows.txt-20071114035000-q36a9h57ps06uvnl-1
=== modified file 'doc/en/user-guide/bazaar_workflows.txt'
--- a/doc/en/user-guide/bazaar_workflows.txt	2008-02-24 02:55:24 +0000
+++ b/doc/en/user-guide/bazaar_workflows.txt	2008-02-27 16:41:53 +0000
@@ -15,7 +15,9 @@
 Solo
 ----
 
-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.
+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.
 
 .. image:: images/workflows_single.png
 
@@ -25,20 +27,26 @@
  * rollback to an earlier state
  * tracking of history.
 
-The key features of Bazaar appropriate for this workflow are low administration (no server setup) and ease of use.
+The key features of Bazaar appropriate for this workflow are low administration
+(no server setup) and ease of use.
 
 
 Partner
 -------
 
-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.
+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.
 
 .. image:: images/workflows_peer.png
 
 Advantages over *Solo* are:
 
  * easier sharing of changes
- * each line of each text file can be attributed to a particular change including who changed it, when and why.
+ * each line of each text file can be attributed to a particular change
+   including who changed it, when and why.
 
 When implementing this workflow, Bazaar's advantages over CVS and Subversion include:
 
@@ -49,11 +57,17 @@
 Centralized
 -----------
 
-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.
+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.
 
 .. image:: images/workflows_centralized.png
 
-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:
+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:
 
  * better branching and merging
  * better renaming support.
@@ -62,7 +76,10 @@
 Centralized with local commits
 ------------------------------
 
-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.
+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.
 
 .. image:: images/workflows_localcommit.png
 
@@ -71,13 +88,16 @@
  * Can work offline, e.g. when disconnected during travel
  * Less chance for a bad commit to interfere with everyone else's work
 
-Subversion and CVS do not support this model. Other distributed VCS tools can support it but do so less directly than Bazaar does.
+Subversion and CVS do not support this model. Other distributed VCS tools can
+support it but do so less directly than Bazaar does.
 
 
 Decentralized with shared mainline
 ----------------------------------
 
-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.
+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.
 
 .. image:: images/workflows_shared.png
 
@@ -95,7 +115,11 @@
 Decentralized with human gatekeeper
 -----------------------------------
 
-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.
+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.
 
 .. image:: images/workflows_gatekeeper.png
 
@@ -104,25 +128,36 @@
  * Code is always reviewed before it enters the mainline
  * Tighter control over when changes get incorporated into the mainline.
 
-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.
+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.
 
 
 Decentralized with automatic gatekeeper
 ---------------------------------------
 
-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
-mainline.
+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 mainline.
 
-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.)
+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.)
 
 .. image:: images/workflows_pqm.png
 
 Advantages over *Decentralized with human gatekeeper*:
 
- * Code is always tested before it enters the mainline (so the integrity of the mainline is higher)
+ * Code is always tested before it enters the mainline (so the integrity of the
+   mainline is higher)
  * Scales better as teams grow.
 
-A companion tool of Bazaar's called Patch Queue Manager (PQM) can provide the automated gatekeeper capability.
+A companion tool of Bazaar's called Patch Queue Manager (PQM) can provide the
+automated gatekeeper capability.
 
 
 Implementing a workflow




More information about the bazaar-commits mailing list