← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/en/admin-guide/hooks-plugins.txt

  • Committer: Neil Martinsen-Burrell
  • Date: 2009-12-11 00:00:04 UTC
  • mto: (4892.1.1 integration)
  • mto: This revision was merged to the branch mainline in revision 4893.
  • Revision ID: nmb@wartburg.edu-20091211000004-zwb6gatjrsig4q1g
Fixes from Vicent and Martins reviews

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/en/admin-guide/hooks-plugins.txt
35
35
------------------
36
36
 
37
37
A common need is for every change made on a branch to send an email message to
38
 
some address, most often a mailing list.  These plugins provide that
39
 
capability in a number of different ways.  The `email` plugin sends email
40
 
from each individual developer's computer.  This can be useful for situations
41
 
that want to track what each individual developer is working on.  On the
42
 
downside, it requires that every developer's branches be configured
43
 
individually to use the same plugin.  The next two plugins `hookless-email`
44
 
and `email-notifier` are designed to run on a central server whenever changes
45
 
happen on centrally stored branches.
 
38
some address, most often a mailing list.  These plugins provide that capability
 
39
in a number of different ways.  
 
40
 
 
41
The `email` plugin sends email from each individual developer's computer.  This
 
42
can be useful for situations that want to track what each individual developer
 
43
is working on.  On the downside, it requires that every developer's branches be
 
44
configured individually to use the same plugin.  
 
45
 
 
46
The next two plugins `hookless-email` and `email-notifier` address this concern
 
47
by running on a central server whenever changes happen on centrally stored
 
48
branches.
46
49
 
47
50
email
48
51
~~~~~
174
177
(see `Back-up and restore <backup.html>`_ for more details on backups).  One
175
178
way to do this using Bazaar's workflows is to make the branch where changes
176
179
happen into a bound branch of the mirror branch.  Then, when commits happen on
177
 
the working branch, they will also happen on the mirror branch.  It is possible
178
 
to make a chain of bound branches to create multiple mirrors.  Note that
 
180
the working branch, they will also happen on the mirror branch.  Note that
179
181
commits to bound branches do *not* update the mirror branch's working copy, so
180
182
if the mirror branch is more than just a backup of the complete history of the
181
183
branch, for example if it is being served as a web page, then additional