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