Merge lp://staging/~nmb/bzr/admin-guide-loggerhead-plugins into lp://staging/bzr

This adds additional material on using Loggerhead and using plugins to extend Bazaar.

 review: needs_fixing

I really like the way you added examples for most of the plugins.

>>>>> "Neil" == Neil Martinsen-Burrell <email address hidden> writes:

<snip/>

    Neil> === modified file 'doc/en/admin-guide/code-browsing.txt'
    Neil> --- doc/en/admin-guide/code-browsing.txt 2009-12-07 18:35:29 +0000
    Neil> +++ doc/en/admin-guide/code-browsing.txt 2009-12-07 18:35:29 +0000

<snip/>

    Neil> Loggerhead
    Neil> ----------

    Neil> +Loggerhead is a code browsing interface for Bazaar branches (originally
    Neil> +developed for Launchpad). To see an example of Loggerhead in action, browse

loggerhead wasn't developed for launchpad, it has been *used*
(and still is !) but it started elsewhere :)

I'll add review requests for beuno and mwhudson as I think they
should be able to spot obvious mistakes I may have missed, but I
think you've got a nice introduction there.

<snip/>

    Neil> +Although directions for installing these on Ubuntu Linux are given, most other
    Neil> +Linux distributions should package these dependencies, making installation
    Neil> +easy. For Windows and Mac OS X, the should all be ``easy_install``-able or at

s/the should/they should/

<snip/>

    Neil> Email Notification
    Neil> ------------------

    Neil> +A common need is for every change made on a branch to send an email message to
    Neil> +some address, most often a mailing list. These plugins provide that
    Neil> +capability in a number of different ways. The `email` plugin sends email
    Neil> +from each individual developer's computer. This can be useful for situations
    Neil> +that want to track what each individual developer is working on. On the
    Neil> +downside, it requires that every developer's branches be configured
    Neil> +individually to use the same plugin. The next two plugins `hookless-email`
    Neil> +and `email-notifier` are designed to run on a central server whenever changes
    Neil> +happen on centrally stored branches.

Start a new paragraph for this last sentence to make it clear
that there are really two different ways to implement the
notifications. Also, you may want to add a remark that the later
mean address the downside you mentioned in the former (that may
not be so obvious for a casual reader).

<snip/>

    Neil> Mirroring
    Neil> ---------

    Neil> +Sometimes it is useful to ensure that one branch exists as an exact copy of
    Neil> +another. This can be used to provide simple backup facilities or redundancy
    Neil> +(see `Back-up and restore <backup.html>`_ for more details on backups). One
    Neil> +way to do this using Bazaar's workflows is to make the branch where changes
    Neil> +happen into a bound branch of the mirror branch. Then, when commits happen on
    Neil> +the working branch, they will also happen on the mirror branch. It is possible
    Neil> +to make a chain of bound branches to create multiple mirrors.

Huh ? I'm pretty sure you can't do that, a bound branch can't be
the target of another bound branch because we don't check for
loops.

    Neil> +Note that
    Neil> +commits to bound branches do *not* update the mirror branch's working copy, so
...

Looks good, minus the comments from Vincent.
The only other thing I'd add, is point to the loggerhead readme, either locally or online.

Martin and Vincent's comments addressed in the branch.

> Martin and Vincent's comments addressed in the branch.

Almost, you seem to have miss the two last ones :)

    Neil> +Note that
    Neil> +commits to bound branches do *not* update the mirror branch's working copy, so
    Neil> +if the mirror branch is more than just a backup of the complete history of the
    Neil> +branch, for example if it is being served as a web page, then additional
    Neil> +plugins are necessary.
    Neil> +
    Neil> +push_and_update
    Neil> +~~~~~~~~~~~~~~~
    Neil> +
    Neil> +This plugin updates Bazaar's ``push`` command to also update the remote
    Neil> +working copy. It can only work over connections that imply filesystem or SSH
    Neil> +access to the remote working copy (``bzr+ssh://``, ``sftp://`` and
    Neil> +``file://``). Also, it is only useful when the remote branch is updated with
    Neil> +an explicit ``push`` command.
    Neil> +

    Neil> +.. TODO: check that the list of URLs is correct

Did you ? :-)

If so, please remove that comment, it's kind of scary :)

<snip/>

    Neil> Other Useful Plugins
    Neil> --------------------
    Neil> +
    Neil> +pqm (plugin)
    Neil> +~~~~~~~~~~~~
    Neil> +
    Neil> +Discussed further under `PQM <integration.html#patch-queue-manager-pqm>`_, this
    Neil> +plugin submits each commit on a branch to the Patch Queue Manager, which can
    Neil> +run the test suite before committing that revision to another branch.

That's not accurate, the plugin does nothing by itself, it
provides support for *submitting* merge requests to a remote pqm.

Got the last two as well. The URL list was correct as written and I used your sentence to describe the PQM plugin (albeit not well, since I've never used it).

Scratching head... did you forget to push then ?

The ..TODO is still present and the pqm description still says: 'this
plugin submits each commit'

I can do that for you if you want, but I don't want to miss one of your commits for a misunderstanding.

> Scratching head... did you forget to push then ?

Sorry, pushed to the wrong branch. Should be fixed now. (Updating soon.)

Ok, I sorted it out, you pushed to both the branch and the pre-requisite one, so the diff is empty here (but I got it locally).

I'll merge.