<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Bazaar Developer Guide — Bazaar 2.6.0 documentation</title>
<link rel="stylesheet" href="_static/default.css" type="text/css" />
<link rel="stylesheet" href="_static/pygments.css" type="text/css" />
<script type="text/javascript">
var DOCUMENTATION_OPTIONS = {
URL_ROOT: './',
VERSION: '2.6.0',
COLLAPSE_INDEX: false,
FILE_SUFFIX: '.html',
HAS_SOURCE: true
};
</script>
<script type="text/javascript" src="_static/jquery.js"></script>
<script type="text/javascript" src="_static/underscore.js"></script>
<script type="text/javascript" src="_static/doctools.js"></script>
<link rel="shortcut icon" href="_static/bzr.ico"/>
<link rel="top" title="Bazaar 2.6.0 documentation" href="index.html" />
<link rel="next" title="Bazaar Testing Guide" href="testing.html" />
<link rel="prev" title="Tracking Bugs in Bazaar" href="bug-handling.html" />
<link rel="stylesheet" href="_static/bzr-doc.css" type="text/css" />
</head>
<body>
<div class="related">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="testing.html" title="Bazaar Testing Guide"
accesskey="N">next</a></li>
<li class="right" >
<a href="bug-handling.html" title="Tracking Bugs in Bazaar"
accesskey="P">previous</a> |</li>
<li><a href="http://bazaar.canonical.com/">
<img src="_static/bzr icon 16.png" /> Home</a> | </li>
<a href="http://doc.bazaar.canonical.com/en/">Documentation</a> | </li>
<li><a href="index.html">Developer Document Catalog (2.6.0)</a> »</li>
</ul>
</div>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body">
<div class="section" id="bazaar-developer-guide">
<h1>Bazaar Developer Guide<a class="headerlink" href="#bazaar-developer-guide" title="Permalink to this headline">¶</a></h1>
<p>This document describes the Bazaar internals and the development process.
It’s meant for people interested in developing Bazaar, and some parts will
also be useful to people developing Bazaar plugins.</p>
<p>If you have any questions or something seems to be incorrect, unclear or
missing, please talk to us in <tt class="docutils literal"><span class="pre">irc://irc.freenode.net/#bzr</span></tt>, or write to
the Bazaar mailing list. To propose a correction or addition to this
document, send a merge request or new text to the mailing list.</p>
<p>The latest developer documentation can be found online at
<a class="reference external" href="http://doc.bazaar.canonical.com/developers/">http://doc.bazaar.canonical.com/developers/</a>.</p>
<div class="section" id="getting-started">
<h2>Getting Started<a class="headerlink" href="#getting-started" title="Permalink to this headline">¶</a></h2>
<div class="section" id="exploring-the-bazaar-platform">
<h3>Exploring the Bazaar Platform<a class="headerlink" href="#exploring-the-bazaar-platform" title="Permalink to this headline">¶</a></h3>
<p>Before making changes, it’s a good idea to explore the work already
done by others. Perhaps the new feature or improvement you’re looking
for is available in another plug-in already? If you find a bug,
perhaps someone else has already fixed it?</p>
<p>To answer these questions and more, take a moment to explore the
overall Bazaar Platform. Here are some links to browse:</p>
<ul class="simple">
<li>The Plugins page on the Wiki - <a class="reference external" href="http://wiki.bazaar.canonical.com/BzrPlugins">http://wiki.bazaar.canonical.com/BzrPlugins</a></li>
<li>The Bazaar product family on Launchpad - <a class="reference external" href="https://launchpad.net/bazaar">https://launchpad.net/bazaar</a></li>
<li>Bug Tracker for the core product - <a class="reference external" href="https://bugs.launchpad.net/bzr/">https://bugs.launchpad.net/bzr/</a></li>
</ul>
<p>If nothing else, perhaps you’ll find inspiration in how other developers
have solved their challenges.</p>
</div>
<div class="section" id="finding-something-to-do">
<h3>Finding Something To Do<a class="headerlink" href="#finding-something-to-do" title="Permalink to this headline">¶</a></h3>
<p>Ad-hoc performance work can also be done. One useful tool is the ‘evil’ debug
flag. For instance running <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">-Devil</span> <span class="pre">commit</span> <span class="pre">-m</span> <span class="pre">"test"</span></tt> will log a backtrace
to the bzr log file for every method call which triggers a slow or non-scalable
part of the bzr library. So checking that a given command with <tt class="docutils literal"><span class="pre">-Devil</span></tt> has
no backtraces logged to the log file is a good way to find problem function
calls that might be nested deep in the code base.</p>
</div>
<div class="section" id="planning-and-discussing-changes">
<h3>Planning and Discussing Changes<a class="headerlink" href="#planning-and-discussing-changes" title="Permalink to this headline">¶</a></h3>
<p>There is a very active community around Bazaar. Mostly we meet on IRC
(#bzr on irc.freenode.net) and on the mailing list. To join the Bazaar
community, see <a class="reference external" href="http://wiki.bazaar.canonical.com/BzrSupport">http://wiki.bazaar.canonical.com/BzrSupport</a>.</p>
<p>If you are planning to make a change, it’s a very good idea to mention it
on the IRC channel and/or on the mailing list. There are many advantages
to involving the community before you spend much time on a change.
These include:</p>
<ul class="simple">
<li>you get to build on the wisdom of others, saving time</li>
<li>if others can direct you to similar code, it minimises the work to be done</li>
<li>it assists everyone in coordinating direction, priorities and effort.</li>
</ul>
<p>In summary, maximising the input from others typically minimises the
total effort required to get your changes merged. The community is
friendly, helpful and always keen to welcome newcomers.</p>
</div>
<div class="section" id="bazaar-development-in-a-nutshell">
<h3>Bazaar Development in a Nutshell<a class="headerlink" href="#bazaar-development-in-a-nutshell" title="Permalink to this headline">¶</a></h3>
<p>One of the fun things about working on a version control system like Bazaar is
that the users have a high level of proficiency in contributing back into
the tool. Consider the following very brief introduction to contributing back
to Bazaar. More detailed instructions are in the following sections.</p>
<div class="section" id="making-the-change">
<h4>Making the change<a class="headerlink" href="#making-the-change" title="Permalink to this headline">¶</a></h4>
<p>First, get a local copy of the development mainline (See <a class="reference internal" href="#why-make-a-local-copy-of-bzr-dev">Why make a local
copy of bzr.dev?</a>.)</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr init-repo ~/bzr
$ cd ~/bzr
$ bzr branch lp:bzr bzr.dev
</pre></div>
</div>
<p>Now make your own branch:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr branch bzr.dev 123456-my-bugfix
</pre></div>
</div>
<p>This will give you a branch called “123456-my-bugfix” that you can work on
and commit in. Here, you can study the code, make a fix or a new feature.
Feel free to commit early and often (after all, it’s your branch!).</p>
<p>Documentation improvements are an easy place to get started giving back to the
Bazaar project. The documentation is in the <cite>doc/</cite> subdirectory of the Bazaar
source tree.</p>
<p>When you are done, make sure that you commit your last set of changes as well!
Once you are happy with your changes, ask for them to be merged, as described
below.</p>
</div>
<div class="section" id="making-a-merge-proposal">
<h4>Making a Merge Proposal<a class="headerlink" href="#making-a-merge-proposal" title="Permalink to this headline">¶</a></h4>
<p>The Bazaar developers use Launchpad to further enable a truly distributed
style of development. Anyone can propose a branch for merging into the Bazaar
trunk. To start this process, you need to push your branch to Launchpad. To
do this, you will need a Launchpad account and user name, e.g.
<cite>your_lp_username</cite>. You can push your branch to Launchpad directly from
Bazaar:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr push lp:~<your_lp_username>/bzr/meaningful_name_here
</pre></div>
</div>
<p>After you have pushed your branch, you will need to propose it for merging to
the Bazaar trunk. Go to
<<a class="reference external" href="https://launchpad.net">https://launchpad.net</a>/~<your_lp_username>/bzr/meaningful_name_here> and choose
“Propose for merging into another branch”. Select “lp:bzr” to hand
your changes off to the Bazaar developers for review and merging.</p>
<p>Alternatively, after pushing you can use the <tt class="docutils literal"><span class="pre">lp-propose</span></tt> command to
create the merge proposal.</p>
<p>Using a meaningful name for your branch will help you and the reviewer(s)
better track the submission. Use a very succint description of your submission
and prefix it with bug number if needed (lp:~mbp/bzr/484558-merge-directory
for example). Alternatively, you can suffix with the bug number
(lp:~jameinel/bzr/export-file-511987).</p>
</div>
<div class="section" id="review-cover-letters">
<h4>Review cover letters<a class="headerlink" href="#review-cover-letters" title="Permalink to this headline">¶</a></h4>
<p>Please put a “cover letter” on your merge request explaining:</p>
<ul class="simple">
<li>the reason <strong>why</strong> you’re making this change</li>
<li><strong>how</strong> this change achieves this purpose</li>
<li>anything else you may have fixed in passing</li>
<li>anything significant that you thought of doing, such as a more
extensive fix or a different approach, but didn’t or couldn’t do now</li>
</ul>
<p>A good cover letter makes reviewers’ lives easier because they can decide
from the letter whether they agree with the purpose and approach, and then
assess whether the patch actually does what the cover letter says.
Explaining any “drive-by fixes” or roads not taken may also avoid queries
from the reviewer. All in all this should give faster and better reviews.
Sometimes writing the cover letter helps the submitter realize something
else they need to do. The size of the cover letter should be proportional
to the size and complexity of the patch.</p>
</div>
<div class="section" id="why-make-a-local-copy-of-bzr-dev">
<h4>Why make a local copy of bzr.dev?<a class="headerlink" href="#why-make-a-local-copy-of-bzr-dev" title="Permalink to this headline">¶</a></h4>
<p>Making a local mirror of bzr.dev is not strictly necessary, but it means</p>
<ul>
<li><p class="first">You can use that copy of bzr.dev as your main bzr executable, and keep it
up-to-date using <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">pull</span></tt>.</p>
</li>
<li><p class="first">Certain operations are faster, and can be done when offline. For example:</p>
<ul class="simple">
<li><tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">bundle</span></tt></li>
<li><tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">diff</span> <span class="pre">-r</span> <span class="pre">ancestor:...</span></tt></li>
<li><tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">merge</span></tt></li>
</ul>
</li>
<li><p class="first">When it’s time to create your next branch, it’s more convenient. When you
have further contributions to make, you should do them in their own branch:</p>
<div class="highlight-python"><div class="highlight"><pre>$ cd ~/bzr
$ bzr branch bzr.dev additional_fixes
$ cd additional_fixes # hack, hack, hack
</pre></div>
</div>
</li>
</ul>
</div>
</div>
<div class="section" id="understanding-the-development-process">
<h3>Understanding the Development Process<a class="headerlink" href="#understanding-the-development-process" title="Permalink to this headline">¶</a></h3>
<p>The development team follows many practices including:</p>
<ul class="simple">
<li>a public roadmap and planning process in which anyone can participate</li>
<li>time based milestones everyone can work towards and plan around</li>
<li>extensive code review and feedback to contributors</li>
<li>complete and rigorous test coverage on any code contributed</li>
<li>automated validation that all tests still pass before code is merged
into the main code branch.</li>
</ul>
<p>The key tools we use to enable these practices are:</p>
<ul class="simple">
<li>Launchpad - <a class="reference external" href="https://launchpad.net/">https://launchpad.net/</a></li>
<li>Bazaar - <a class="reference external" href="http://bazaar.canonical.com/">http://bazaar.canonical.com/</a></li>
<li>Patch Queue Manager - <a class="reference external" href="https://launchpad.net/pqm/">https://launchpad.net/pqm/</a></li>
</ul>
<p>For further information, see <<a class="reference external" href="http://wiki.bazaar.canonical.com/BzrDevelopment">http://wiki.bazaar.canonical.com/BzrDevelopment</a>>.</p>
</div>
<div class="section" id="preparing-a-sandbox-for-making-changes-to-bazaar">
<h3>Preparing a Sandbox for Making Changes to Bazaar<a class="headerlink" href="#preparing-a-sandbox-for-making-changes-to-bazaar" title="Permalink to this headline">¶</a></h3>
<p>Bazaar supports many ways of organising your work. See
<a class="reference external" href="http://wiki.bazaar.canonical.com/SharedRepositoryLayouts">http://wiki.bazaar.canonical.com/SharedRepositoryLayouts</a> for a summary of the
popular alternatives.</p>
<p>Of course, the best choice for you will depend on numerous factors:
the number of changes you may be making, the complexity of the changes, etc.
As a starting suggestion though:</p>
<ul>
<li><p class="first">create a local copy of the main development branch (bzr.dev) by using
this command:</p>
<div class="highlight-python"><div class="highlight"><pre>bzr branch lp:bzr bzr.dev
</pre></div>
</div>
</li>
<li><p class="first">keep your copy of bzr.dev pristine (by not developing in it) and keep
it up to date (by using bzr pull)</p>
</li>
<li><p class="first">create a new branch off your local bzr.dev copy for each issue
(bug or feature) you are working on.</p>
</li>
</ul>
<p>This approach makes it easy to go back and make any required changes
after a code review. Resubmitting the change is then simple with no
risk of accidentally including edits related to other issues you may
be working on. After the changes for an issue are accepted and merged,
the associated branch can be deleted or archived as you wish.</p>
</div>
<div class="section" id="navigating-the-code-base">
<h3>Navigating the Code Base<a class="headerlink" href="#navigating-the-code-base" title="Permalink to this headline">¶</a></h3>
<p>Some of the key files in this directory are:</p>
<dl class="docutils">
<dt>bzr</dt>
<dd>The command you run to start Bazaar itself. This script is pretty
short and just does some checks then jumps into bzrlib.</dd>
<dt>README</dt>
<dd>This file covers a brief introduction to Bazaar and lists some of its
key features.</dd>
<dt>setup.py</dt>
<dd>Installs Bazaar system-wide or to your home directory. To perform
development work on Bazaar it is not required to run this file - you
can simply run the bzr command from the top level directory of your
development copy. Note: That if you run setup.py this will create a
‘build’ directory in your development branch. There’s nothing wrong
with this but don’t be confused by it. The build process puts a copy
of the main code base into this build directory, along with some other
files. You don’t need to go in here for anything discussed in this
guide.</dd>
<dt>bzrlib</dt>
<dd>Possibly the most exciting folder of all, bzrlib holds the main code
base. This is where you will go to edit python files and contribute to
Bazaar.</dd>
<dt>doc</dt>
<dd>Holds documentation on a whole range of things on Bazaar from the
origination of ideas within the project to information on Bazaar
features and use cases. Within this directory there is a subdirectory
for each translation into a human language. All the documentation
is in the ReStructuredText markup language.</dd>
<dt>doc/developers</dt>
<dd>Documentation specifically targeted at Bazaar and plugin developers.
(Including this document.)</dd>
</dl>
<p>doc/en/release-notes/</p>
<blockquote>
<div>Detailed changes in each Bazaar release (there is one file by series:
bzr-2.3.txt, bzr-2.4.txt, etc) that can affect users or plugin
developers.</div></blockquote>
<p>doc/en/whats-new/</p>
<blockquote>
<div>High-level summaries of changes in each Bazaar release (there is one
file by series: whats-new-in-2.3.txt, whats-new-in-2.4.txt, etc).</div></blockquote>
<p>Automatically-generated API reference information is available at
<<a class="reference external" href="http://people.canonical.com/~mwh/bzrlibapi/">http://people.canonical.com/~mwh/bzrlibapi/</a>>.</p>
<p>See also the <a class="reference external" href="http://doc.bazaar.canonical.com/developers/overview.html">Bazaar Architectural Overview</a>.</p>
</div>
</div>
<div class="section" id="core-topics">
<h2>Core Topics<a class="headerlink" href="#core-topics" title="Permalink to this headline">¶</a></h2>
<div class="section" id="evolving-interfaces">
<h3>Evolving Interfaces<a class="headerlink" href="#evolving-interfaces" title="Permalink to this headline">¶</a></h3>
<p>We don’t change APIs in stable branches: any supported symbol in a stable
release of bzr must not be altered in any way that would result in
breaking existing code that uses it. That means that method names,
parameter ordering, parameter names, variable and attribute names etc must
not be changed without leaving a ‘deprecated forwarder’ behind. This even
applies to modules and classes.</p>
<p>If you wish to change the behaviour of a supported API in an incompatible
way, you need to change its name as well. For instance, if I add an optional keyword
parameter to branch.commit - that’s fine. On the other hand, if I add a
keyword parameter to branch.commit which is a <em>required</em> transaction
object, I should rename the API - i.e. to ‘branch.commit_transaction’.</p>
<blockquote>
<div>(Actually, that may break code that provides a new implementation of
<tt class="docutils literal"><span class="pre">commit</span></tt> and doesn’t expect to receive the parameter.)</div></blockquote>
<p>When renaming such supported API’s, be sure to leave a deprecated_method (or
_function or ...) behind which forwards to the new API. See the
bzrlib.symbol_versioning module for decorators that take care of the
details for you - such as updating the docstring, and issuing a warning
when the old API is used.</p>
<p>For unsupported API’s, it does not hurt to follow this discipline, but it’s
not required. Minimally though, please try to rename things so that
callers will at least get an AttributeError rather than weird results.</p>
<div class="section" id="deprecation-decorators">
<h4>Deprecation decorators<a class="headerlink" href="#deprecation-decorators" title="Permalink to this headline">¶</a></h4>
<p><tt class="docutils literal"><span class="pre">bzrlib.symbol_versioning</span></tt> provides decorators that can be attached to
methods, functions, and other interfaces to indicate that they should no
longer be used. For example:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="nd">@deprecated_method</span><span class="p">(</span><span class="n">deprecated_in</span><span class="p">((</span><span class="mi">0</span><span class="p">,</span> <span class="mi">1</span><span class="p">,</span> <span class="mi">4</span><span class="p">)))</span>
<span class="k">def</span> <span class="nf">foo</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
<span class="k">return</span> <span class="bp">self</span><span class="o">.</span><span class="n">_new_foo</span><span class="p">()</span>
</pre></div>
</div>
<p>To deprecate a static method you must call <tt class="docutils literal"><span class="pre">deprecated_function</span></tt>
(<strong>not</strong> method), after the staticmethod call:</p>
<div class="highlight-python"><div class="highlight"><pre>@staticmethod
@deprecated_function(deprecated_in((0, 1, 4)))
def create_repository(base, shared=False, format=None):
</pre></div>
</div>
<p>When you deprecate an API, you should not just delete its tests, because
then we might introduce bugs in them. If the API is still present at all,
it should still work. The basic approach is to use
<tt class="docutils literal"><span class="pre">TestCase.applyDeprecated</span></tt> which in one step checks that the API gives
the expected deprecation message, and also returns the real result from
the method, so that tests can keep running.</p>
<p>Deprecation warnings will be suppressed for final releases, but not for
development versions or release candidates, or when running <tt class="docutils literal"><span class="pre">bzr</span>
<span class="pre">selftest</span></tt>. This gives developers information about whether their code is
using deprecated functions, but avoids confusing users about things they
can’t fix.</p>
</div>
</div>
<div class="section" id="general-guidelines">
<h3>General Guidelines<a class="headerlink" href="#general-guidelines" title="Permalink to this headline">¶</a></h3>
<div class="section" id="copyright">
<h4>Copyright<a class="headerlink" href="#copyright" title="Permalink to this headline">¶</a></h4>
<p>The copyright policy for bzr was recently made clear in this email (edited
for grammatical correctness):</p>
<div class="highlight-python"><div class="highlight"><pre>The attached patch cleans up the copyright and license statements in
the bzr source. It also adds tests to help us remember to add them
with the correct text.
We had the problem that lots of our files were "Copyright Canonical
Development Ltd" which is not a real company, and some other variations
on this theme. Also, some files were missing the GPL statements.
I want to be clear about the intent of this patch, since copyright can
be a little controversial.
1) The big motivation for this is not to shut out the community, but
just to clean up all of the invalid copyright statements.
2) It has been the general policy for bzr that we want a single
copyright holder for all of the core code. This is following the model
set by the FSF, which makes it easier to update the code to a new
license in case problems are encountered. (For example, if we want to
upgrade the project universally to GPL v3 it is much simpler if there is
a single copyright holder). It also makes it clearer if copyright is
ever debated, there is a single holder, which makes it easier to defend
in court, etc. (I think the FSF position is that if you assign them
copyright, they can defend it in court rather than you needing to, and
I'm sure Canonical would do the same).
As such, Canonical has requested copyright assignments from all of the
major contributers.
3) If someone wants to add code and not attribute it to Canonical, there
is a specific list of files that are excluded from this check. And the
test failure indicates where that is, and how to update it.
4) If anyone feels that I changed a copyright statement incorrectly, just
let me know, and I'll be happy to correct it. Whenever you have large
mechanical changes like this, it is possible to make some mistakes.
Just to reiterate, this is a community project, and it is meant to stay
that way. Core bzr code is copyright Canonical for legal reasons, and
the tests are just there to help us maintain that.
</pre></div>
</div>
</div>
</div>
</div>
<div class="section" id="miscellaneous-topics">
<h2>Miscellaneous Topics<a class="headerlink" href="#miscellaneous-topics" title="Permalink to this headline">¶</a></h2>
<div class="section" id="debugging">
<h3>Debugging<a class="headerlink" href="#debugging" title="Permalink to this headline">¶</a></h3>
<p>Bazaar has a few facilities to help debug problems by going into <a class="reference external" href="http://docs.python.org/lib/debugger-commands.html">pdb</a>, the
Python debugger.</p>
<p>If the <tt class="docutils literal"><span class="pre">BZR_PDB</span></tt> environment variable is set
then bzr will go into pdb post-mortem mode when an unhandled exception
occurs.</p>
<p>If you send a SIGQUIT or SIGBREAK signal to bzr then it will drop into the
debugger immediately. SIGQUIT can be generated by pressing Ctrl-\ on
Unix. SIGBREAK is generated with Ctrl-Pause on Windows (some laptops have
this as Fn-Pause). You can continue execution by typing <tt class="docutils literal"><span class="pre">c</span></tt>. This can
be disabled if necessary by setting the environment variable
<tt class="docutils literal"><span class="pre">BZR_SIGQUIT_PDB=0</span></tt>.</p>
<p>All tests inheriting from bzrlib.tests.TestCase can use <tt class="docutils literal"><span class="pre">self.debug()</span></tt>
instead of the longer <tt class="docutils literal"><span class="pre">import</span> <span class="pre">pdb;</span> <span class="pre">pdb.set_trace()</span></tt>. The former also works
when <tt class="docutils literal"><span class="pre">stdin/stdout</span></tt> are redirected (by using the original <tt class="docutils literal"><span class="pre">stdin/stdout</span></tt>
file handles at the start of the <tt class="docutils literal"><span class="pre">bzr</span></tt> script) while the later doesn’t.
<tt class="docutils literal"><span class="pre">bzrlib.debug.set_trace()</span></tt> also uses the original <tt class="docutils literal"><span class="pre">stdin/stdout</span></tt> file
handles.</p>
</div>
<div class="section" id="debug-flags">
<h3>Debug Flags<a class="headerlink" href="#debug-flags" title="Permalink to this headline">¶</a></h3>
<p>Bazaar accepts some global options starting with <tt class="docutils literal"><span class="pre">-D</span></tt> such as
<tt class="docutils literal"><span class="pre">-Dhpss</span></tt>. These set a value in <cite>bzrlib.debug.debug_flags</cite>, and
typically cause more information to be written to the trace file. Most
<cite>mutter</cite> calls should be guarded by a check of those flags so that we
don’t write out too much information if it’s not needed.</p>
<p>Debug flags may have effects other than just emitting trace messages.</p>
<p>Run <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">help</span> <span class="pre">global-options</span></tt> to see them all.</p>
<p>These flags may also be set as a comma-separated list in the
<tt class="docutils literal"><span class="pre">debug_flags</span></tt> option in e.g. <tt class="docutils literal"><span class="pre">~/.bazaar/bazaar.conf</span></tt>. (Note that it
must be in this global file, not in the branch or location configuration,
because it’s currently only loaded at startup time.) For instance you may
want to always record hpss traces and to see full error tracebacks:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="n">debug_flags</span> <span class="o">=</span> <span class="n">hpss</span><span class="p">,</span> <span class="n">error</span>
</pre></div>
</div>
</div>
<div class="section" id="jargon">
<h3>Jargon<a class="headerlink" href="#jargon" title="Permalink to this headline">¶</a></h3>
<dl class="docutils">
<dt>revno</dt>
<dd>Integer identifier for a revision on the main line of a branch.
Revision 0 is always the null revision; others are 1-based
indexes into the branch’s revision history.</dd>
</dl>
</div>
<div class="section" id="unicode-and-encoding-support">
<h3>Unicode and Encoding Support<a class="headerlink" href="#unicode-and-encoding-support" title="Permalink to this headline">¶</a></h3>
<p>This section discusses various techniques that Bazaar uses to handle
characters that are outside the ASCII set.</p>
<div class="section" id="command-outf">
<h4><tt class="docutils literal"><span class="pre">Command.outf</span></tt><a class="headerlink" href="#command-outf" title="Permalink to this headline">¶</a></h4>
<p>When a <tt class="docutils literal"><span class="pre">Command</span></tt> object is created, it is given a member variable
accessible by <tt class="docutils literal"><span class="pre">self.outf</span></tt>. This is a file-like object, which is bound to
<tt class="docutils literal"><span class="pre">sys.stdout</span></tt>, and should be used to write information to the screen,
rather than directly writing to <tt class="docutils literal"><span class="pre">sys.stdout</span></tt> or calling <tt class="docutils literal"><span class="pre">print</span></tt>.
This file has the ability to translate Unicode objects into the correct
representation, based on the console encoding. Also, the class attribute
<tt class="docutils literal"><span class="pre">encoding_type</span></tt> will effect how unprintable characters will be
handled. This parameter can take one of 3 values:</p>
<blockquote>
<div><dl class="docutils">
<dt>replace</dt>
<dd>Unprintable characters will be represented with a suitable replacement
marker (typically ‘?’), and no exception will be raised. This is for
any command which generates text for the user to review, rather than
for automated processing.
For example: <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">log</span></tt> should not fail if one of the entries has text
that cannot be displayed.</dd>
<dt>strict</dt>
<dd>Attempting to print an unprintable character will cause a UnicodeError.
This is for commands that are intended more as scripting support, rather
than plain user review.
For example: <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">ls</span></tt> is designed to be used with shell scripting. One
use would be <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">ls</span> <span class="pre">--null</span> <span class="pre">--unknowns</span> <span class="pre">|</span> <span class="pre">xargs</span> <span class="pre">-0</span> <span class="pre">rm</span></tt>. If <tt class="docutils literal"><span class="pre">bzr</span></tt>
printed a filename with a ‘?’, the wrong file could be deleted. (At the
very least, the correct file would not be deleted). An error is used to
indicate that the requested action could not be performed.</dd>
<dt>exact</dt>
<dd>Do not attempt to automatically convert Unicode strings. This is used
for commands that must handle conversion themselves.
For example: <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">diff</span></tt> needs to translate Unicode paths, but should
not change the exact text of the contents of the files.</dd>
</dl>
</div></blockquote>
</div>
<div class="section" id="bzrlib-urlutils-unescape-for-display">
<h4><tt class="docutils literal"><span class="pre">bzrlib.urlutils.unescape_for_display</span></tt><a class="headerlink" href="#bzrlib-urlutils-unescape-for-display" title="Permalink to this headline">¶</a></h4>
<p>Because Transports work in URLs (as defined earlier), printing the raw URL
to the user is usually less than optimal. Characters outside the standard
set are printed as escapes, rather than the real character, and local
paths would be printed as <tt class="docutils literal"><span class="pre">file://</span></tt> URLs. The function
<tt class="docutils literal"><span class="pre">unescape_for_display</span></tt> attempts to unescape a URL, such that anything
that cannot be printed in the current encoding stays an escaped URL, but
valid characters are generated where possible.</p>
</div>
</div>
<div class="section" id="c-extension-modules">
<h3>C Extension Modules<a class="headerlink" href="#c-extension-modules" title="Permalink to this headline">¶</a></h3>
<p>We write some extensions in C using pyrex. We design these to work in
three scenarios:</p>
<blockquote>
<div><ul class="simple">
<li>User with no C compiler</li>
<li>User with C compiler</li>
<li>Developers</li>
</ul>
</div></blockquote>
<p>The recommended way to install bzr is to have a C compiler so that the
extensions can be built, but if no C compiler is present, the pure python
versions we supply will work, though more slowly.</p>
<p>For developers we recommend that pyrex be installed, so that the C
extensions can be changed if needed.</p>
<p>For the C extensions, the extension module should always match the
original python one in all respects (modulo speed). This should be
maintained over time.</p>
<p>To create an extension, add rules to setup.py for building it with pyrex,
and with distutils. Now start with an empty .pyx file. At the top add
“include ‘yourmodule.py’”. This will import the contents of foo.py into this
file at build time - remember that only one module will be loaded at
runtime. Now you can subclass classes, or replace functions, and only your
changes need to be present in the .pyx file.</p>
<p>Note that pyrex does not support all 2.4 programming idioms, so some
syntax changes may be required. I.e.</p>
<blockquote>
<div><ul class="simple">
<li>‘from foo import (bar, gam)’ needs to change to not use the brackets.</li>
<li>‘import foo.bar as bar’ needs to be ‘import foo.bar; bar = foo.bar’</li>
</ul>
</div></blockquote>
<p>If the changes are too dramatic, consider
maintaining the python code twice - once in the .pyx, and once in the .py,
and no longer including the .py file.</p>
</div>
<div class="section" id="making-installers-for-os-windows">
<h3>Making Installers for OS Windows<a class="headerlink" href="#making-installers-for-os-windows" title="Permalink to this headline">¶</a></h3>
<p>To build a win32 installer, see the instructions on the wiki page:
<a class="reference external" href="http://wiki.bazaar.canonical.com/BzrWin32Installer">http://wiki.bazaar.canonical.com/BzrWin32Installer</a></p>
</div>
</div>
<div class="section" id="core-developer-tasks">
<h2>Core Developer Tasks<a class="headerlink" href="#core-developer-tasks" title="Permalink to this headline">¶</a></h2>
<div class="section" id="overview">
<h3>Overview<a class="headerlink" href="#overview" title="Permalink to this headline">¶</a></h3>
<div class="section" id="what-is-a-core-developer">
<h4>What is a Core Developer?<a class="headerlink" href="#what-is-a-core-developer" title="Permalink to this headline">¶</a></h4>
<p>While everyone in the Bazaar community is welcome and encouraged to
propose and submit changes, a smaller team is reponsible for pulling those
changes together into a cohesive whole. In addition to the general developer
stuff covered above, “core” developers have responsibility for:</p>
<ul class="simple">
<li>reviewing changes</li>
<li>planning releases</li>
<li>managing releases (see <a class="reference external" href="http://doc.bazaar.canonical.com/developers/releasing.html">Releasing Bazaar</a>)</li>
</ul>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Removing barriers to community participation is a key reason for adopting
distributed VCS technology. While DVCS removes many technical barriers,
a small number of social barriers are often necessary instead.
By documenting how the above things are done, we hope to
encourage more people to participate in these activities, keeping the
differences between core and non-core contributors to a minimum.</p>
</div>
</div>
<div class="section" id="communicating-and-coordinating">
<h4>Communicating and Coordinating<a class="headerlink" href="#communicating-and-coordinating" title="Permalink to this headline">¶</a></h4>
<p>While it has many advantages, one of the challenges of distributed
development is keeping everyone else aware of what you’re working on.
There are numerous ways to do this:</p>
<ol class="arabic simple">
<li>Assign bugs to yourself in Launchpad</li>
<li>Mention it on the mailing list</li>
<li>Mention it on IRC</li>
</ol>
<p>As well as the email notifcations that occur when merge requests are sent
and reviewed, you can keep others informed of where you’re spending your
energy by emailing the <strong>bazaar-commits</strong> list implicitly. To do this,
install and configure the Email plugin. One way to do this is add these
configuration settings to your central configuration file (e.g.
<tt class="docutils literal"><span class="pre">~/.bazaar/bazaar.conf</span></tt>):</p>
<div class="highlight-python"><div class="highlight"><pre>[DEFAULT]
email = Joe Smith <joe.smith@internode.on.net>
smtp_server = mail.internode.on.net:25
</pre></div>
</div>
<p>Then add these lines for the relevant branches in <tt class="docutils literal"><span class="pre">locations.conf</span></tt>:</p>
<div class="highlight-python"><div class="highlight"><pre>post_commit_to = bazaar-commits@lists.canonical.com
post_commit_mailer = smtplib
</pre></div>
</div>
<p>While attending a sprint, RobertCollins’ Dbus plugin is useful for the
same reason. See the documentation within the plugin for information on
how to set it up and configure it.</p>
</div>
</div>
<div class="section" id="planning-releases">
<h3>Planning Releases<a class="headerlink" href="#planning-releases" title="Permalink to this headline">¶</a></h3>
<div class="section" id="bug-triage">
<h4>Bug Triage<a class="headerlink" href="#bug-triage" title="Permalink to this headline">¶</a></h4>
<p>Keeping on top of bugs reported is an important part of ongoing release
planning. Everyone in the community is welcome and encouraged to raise
bugs, confirm bugs raised by others, and nominate a priority. Practically
though, a good percentage of bug triage is often done by the core
developers, partially because of their depth of product knowledge.</p>
<p>With respect to bug triage, core developers are encouraged to play an
active role with particular attention to the following tasks:</p>
<ul class="simple">
<li>keeping the number of unconfirmed bugs low</li>
<li>ensuring the priorities are generally right (everything as critical - or
medium - is meaningless)</li>
<li>looking out for regressions and turning those around sooner rather than later.</li>
</ul>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">As well as prioritizing bugs and nominating them against a
target milestone, Launchpad lets core developers offer to mentor others in
fixing them.</p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="sphinxsidebar">
<div class="sphinxsidebarwrapper">
<h3><a href="index.html">Table Of Contents</a></h3>
<ul>
<li><a class="reference internal" href="#">Bazaar Developer Guide</a><ul>
<li><a class="reference internal" href="#getting-started">Getting Started</a><ul>
<li><a class="reference internal" href="#exploring-the-bazaar-platform">Exploring the Bazaar Platform</a></li>
<li><a class="reference internal" href="#finding-something-to-do">Finding Something To Do</a></li>
<li><a class="reference internal" href="#planning-and-discussing-changes">Planning and Discussing Changes</a></li>
<li><a class="reference internal" href="#bazaar-development-in-a-nutshell">Bazaar Development in a Nutshell</a><ul>
<li><a class="reference internal" href="#making-the-change">Making the change</a></li>
<li><a class="reference internal" href="#making-a-merge-proposal">Making a Merge Proposal</a></li>
<li><a class="reference internal" href="#review-cover-letters">Review cover letters</a></li>
<li><a class="reference internal" href="#why-make-a-local-copy-of-bzr-dev">Why make a local copy of bzr.dev?</a></li>
</ul>
</li>
<li><a class="reference internal" href="#understanding-the-development-process">Understanding the Development Process</a></li>
<li><a class="reference internal" href="#preparing-a-sandbox-for-making-changes-to-bazaar">Preparing a Sandbox for Making Changes to Bazaar</a></li>
<li><a class="reference internal" href="#navigating-the-code-base">Navigating the Code Base</a></li>
</ul>
</li>
<li><a class="reference internal" href="#core-topics">Core Topics</a><ul>
<li><a class="reference internal" href="#evolving-interfaces">Evolving Interfaces</a><ul>
<li><a class="reference internal" href="#deprecation-decorators">Deprecation decorators</a></li>
</ul>
</li>
<li><a class="reference internal" href="#general-guidelines">General Guidelines</a><ul>
<li><a class="reference internal" href="#copyright">Copyright</a></li>
</ul>
</li>
</ul>
</li>
<li><a class="reference internal" href="#miscellaneous-topics">Miscellaneous Topics</a><ul>
<li><a class="reference internal" href="#debugging">Debugging</a></li>
<li><a class="reference internal" href="#debug-flags">Debug Flags</a></li>
<li><a class="reference internal" href="#jargon">Jargon</a></li>
<li><a class="reference internal" href="#unicode-and-encoding-support">Unicode and Encoding Support</a><ul>
<li><a class="reference internal" href="#command-outf"><tt class="docutils literal"><span class="pre">Command.outf</span></tt></a></li>
<li><a class="reference internal" href="#bzrlib-urlutils-unescape-for-display"><tt class="docutils literal"><span class="pre">bzrlib.urlutils.unescape_for_display</span></tt></a></li>
</ul>
</li>
<li><a class="reference internal" href="#c-extension-modules">C Extension Modules</a></li>
<li><a class="reference internal" href="#making-installers-for-os-windows">Making Installers for OS Windows</a></li>
</ul>
</li>
<li><a class="reference internal" href="#core-developer-tasks">Core Developer Tasks</a><ul>
<li><a class="reference internal" href="#overview">Overview</a><ul>
<li><a class="reference internal" href="#what-is-a-core-developer">What is a Core Developer?</a></li>
<li><a class="reference internal" href="#communicating-and-coordinating">Communicating and Coordinating</a></li>
</ul>
</li>
<li><a class="reference internal" href="#planning-releases">Planning Releases</a><ul>
<li><a class="reference internal" href="#bug-triage">Bug Triage</a></li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
</ul>
<h4>Previous topic</h4>
<p class="topless"><a href="bug-handling.html"
title="previous chapter">Tracking Bugs in Bazaar</a></p>
<h4>Next topic</h4>
<p class="topless"><a href="testing.html"
title="next chapter">Bazaar Testing Guide</a></p>
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="_sources/HACKING.txt"
rel="nofollow">Show Source</a></li>
</ul>
<div id="searchbox" style="display: none">
<h3>Quick search</h3>
<form class="search" action="search.html" method="get">
<input type="text" name="q" />
<input type="submit" value="Go" />
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
<p class="searchtip" style="font-size: 90%">
Enter search terms or a module, class or function name.
</p>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="related">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="testing.html" title="Bazaar Testing Guide"
>next</a></li>
<li class="right" >
<a href="bug-handling.html" title="Tracking Bugs in Bazaar"
>previous</a> |</li>
<li><a href="http://bazaar.canonical.com/">
<img src="_static/bzr icon 16.png" /> Home</a> | </li>
<a href="http://doc.bazaar.canonical.com/en/">Documentation</a> | </li>
<li><a href="index.html">Developer Document Catalog (2.6.0)</a> »</li>
</ul>
</div>
<div class="footer">
© Copyright 2009-2011 Canonical Ltd.
Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.3.
</div>
</body>
</html>
