~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/HACKING.txt

  • Committer: Matt Nordhoff
  • Date: 2009-04-04 02:50:01 UTC
  • mfrom: (4253 +trunk)
  • mto: This revision was merged to the branch mainline in revision 4256.
  • Revision ID: mnordhoff@mattnordhoff.com-20090404025001-z1403k0tatmc8l91
Merge bzr.dev, fixing conflicts.

Show diffs side-by-side

added added

removed removed

Lines of Context:
385
385
We use 4 space indents for blocks, and never use tab characters.  (In vim,
386
386
``set expandtab``.)
387
387
 
 
388
No trailing white space is allowed.
 
389
 
 
390
Unix style newlines (LF) are used.
 
391
 
 
392
Each file must have a newline at the end of it.
 
393
 
388
394
Lines should be no more than 79 characters if at all possible.
389
395
Lines that continue a long statement may be indented in either of 
390
396
two ways:
693
699
=============
694
700
 
695
701
All code should be exercised by the test suite.  See `Guide to Testing
696
 
Bazaar <testing.html>`_ for detailed information about writing tests.
 
702
Bazaar <../../developers/testing.html>`_ for detailed information about writing tests.
697
703
 
698
704
 
699
705
Core Topics
818
824
should be only in the command-line tool.
819
825
 
820
826
 
 
827
Progress and Activity Indications
 
828
---------------------------------
 
829
 
 
830
bzrlib has a way for code to display to the user that stuff is happening
 
831
during a long operation.  There are two particular types: *activity* which
 
832
means that IO is happening on a Transport, and *progress* which means that
 
833
higher-level application work is occurring.  Both are drawn together by
 
834
the `ui_factory`.
 
835
 
 
836
Transport objects are responsible for calling `report_transport_activity`
 
837
when they do IO.
 
838
 
 
839
Progress uses a model/view pattern: application code acts on a
 
840
`ProgressTask` object, which notifies the UI when it needs to be
 
841
displayed.  Progress tasks form a stack.  To create a new progress task on
 
842
top of the stack, call `bzrlib.ui.ui_factory.nested_progress_bar()`, then
 
843
call `update()` on the returned ProgressTask.  It can be updated with just
 
844
a text description, with a numeric count, or with a numeric count and
 
845
expected total count.  If an expected total count is provided the view
 
846
can show the progress moving along towards the expected total.
 
847
 
 
848
The user should call `finish` on the `ProgressTask` when the logical
 
849
operation has finished, so it can be removed from the stack.
 
850
 
 
851
Progress tasks have a complex relatioship with generators: it's a very
 
852
good place to use them, but because python2.4 does not allow ``finally``
 
853
blocks in generators it's hard to clean them up properly.  In this case
 
854
it's probably better to have the code calling the generator allocate a
 
855
progress task for its use and then call `finalize` when it's done, which
 
856
will close it if it was not already closed.  The generator should also
 
857
finish the progress task when it exits, because it may otherwise be a long
 
858
time until the finally block runs.
 
859
 
821
860
 
822
861
Displaying help
823
862
===============
1073
1112
 
1074
1113
Run ``bzr help global-options`` to see them all.
1075
1114
 
 
1115
These flags may also be set as a comma-separated list in the
 
1116
``debug_flags`` option in e.g.  ``~/.bazaar/bazaar.conf``.  (Note that it
 
1117
must be in this global file, not in the branch or location configuration,
 
1118
because it's currently only loaded at startup time.)  For instance you may
 
1119
want to always record hpss traces and to see full error tracebacks::
 
1120
 
 
1121
    debug_flags = hpss, error
 
1122
 
1076
1123
 
1077
1124
Jargon
1078
1125
======