1
============================
2
guidelines for modifying bzr
3
============================
5
* New functionality should have test cases. Preferably write the
6
test before writing the code.
8
In general, you can test at either the command-line level or the
9
internal API level. Choose whichever is appropriate: if adding a
10
new command, or a new command option, then call through run_bzr().
11
It is not necessary to do both.
13
* Before fixing a bug, write a test case so that it does not regress.
15
* Exceptions should be defined inside bzrlib.errors, so that we can
16
see the whole tree at a glance.
18
* Imports should be done at the top-level of the file, unless there is
19
a strong reason to have them lazily loaded when a particular
20
function runs. Import statements have a cost, so try to make sure
21
they don't run inside hot functions.
23
* Please write PEP-8__ compliant code.
25
__ http://www.python.org/peps/pep-0008.html
27
* Module names should always be given fully-qualified,
28
i.e. ``bzrlib.hashcache`` not just ``hashcache``.
35
If you change the behaviour of a command, please update its docstring
36
in bzrlib/commands.py. This is displayed by the 'bzr help' command.
38
If you make a user-visible change, please add a note to the NEWS file.
39
The description should be written to make sense to someone who's just
40
a user of bzr, not a developer: new functions or classes shouldn't be
41
mentioned, but new commands, changes in behaviour or fixed nontrivial
42
bugs should be listed. See the existing entries for an idea of what
added
removed
HACKING
