~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to bzrlib/help_topics.py

  • Committer: Canonical.com Patch Queue Manager
  • Date: 2007-03-20 22:23:07 UTC
  • mfrom: (2363.2.5 dirstate_93681)
  • Revision ID: pqm@pqm.ubuntu.com-20070320222307-30c846e90ac18c65
(John Arbash Meinel) fix bug #93681 by not calling _make_absent for removed entries.

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
# Copyright (C) 2006, 2009 Canonical Ltd
 
1
# Copyright (C) 2006 Canonical Ltd
2
2
#
3
3
# This program is free software; you can redistribute it and/or modify
4
4
# it under the terms of the GNU General Public License as published by
12
12
#
13
13
# You should have received a copy of the GNU General Public License
14
14
# along with this program; if not, write to the Free Software
15
 
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
 
15
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
16
16
 
17
17
"""A collection of extra help information for using bzr.
18
18
 
19
19
Help topics are meant to be help for items that aren't commands, but will
20
20
help bzr become fully learnable without referring to a tutorial.
21
 
 
22
 
Limited formatting of help text is permitted to make the text useful
23
 
both within the reference manual (reStructuredText) and on the screen.
24
 
The help text should be reStructuredText with formatting kept to a
25
 
minimum and, in particular, no headings. The onscreen renderer applies
26
 
the following simple rules before rendering the text:
27
 
 
28
 
    1. A '::' appearing on the end of a line is replaced with ':'.
29
 
    2. Lines starting with a ':' have it stripped.
30
 
 
31
 
These rules mean that literal blocks and field lists respectively can
32
 
be used in the help text, producing sensible input to a manual while
33
 
rendering on the screen naturally.
34
21
"""
35
22
 
36
 
import sys
37
 
 
38
 
import bzrlib
39
 
from bzrlib import (
40
 
    osutils,
41
 
    registry,
42
 
    )
43
 
 
44
 
 
45
 
# Section identifiers (map topics to the right place in the manual)
46
 
SECT_COMMAND = "command"
47
 
SECT_CONCEPT = "concept"
48
 
SECT_HIDDEN =  "hidden"
49
 
SECT_LIST    = "list"
50
 
SECT_PLUGIN  = "plugin"
 
23
from bzrlib import registry
51
24
 
52
25
 
53
26
class HelpTopicRegistry(registry.Registry):
54
27
    """A Registry customized for handling help topics."""
55
28
 
56
 
    def register(self, topic, detail, summary, section=SECT_LIST):
 
29
    def register(self, topic, detail, summary):
57
30
        """Register a new help topic.
58
31
 
59
32
        :param topic: Name of documentation entry
60
33
        :param detail: Function or string object providing detailed
61
34
            documentation for topic.  Function interface is detail(topic).
62
35
            This should return a text string of the detailed information.
63
 
            See the module documentation for details on help text formatting.
64
36
        :param summary: String providing single-line documentation for topic.
65
 
        :param section: Section in reference manual - see SECT_* identifiers.
66
37
        """
67
 
        # The detail is stored as the 'object' and the metadata as the info
68
 
        info=(summary,section)
69
 
        super(HelpTopicRegistry, self).register(topic, detail, info=info)
 
38
        # The detail is stored as the 'object' and the 
 
39
        super(HelpTopicRegistry, self).register(topic, detail, info=summary)
70
40
 
71
 
    def register_lazy(self, topic, module_name, member_name, summary,
72
 
                      section=SECT_LIST):
 
41
    def register_lazy(self, topic, module_name, member_name, summary):
73
42
        """Register a new help topic, and import the details on demand.
74
43
 
75
44
        :param topic: Name of documentation entry
76
45
        :param module_name: The module to find the detailed help.
77
46
        :param member_name: The member of the module to use for detailed help.
78
47
        :param summary: String providing single-line documentation for topic.
79
 
        :param section: Section in reference manual - see SECT_* identifiers.
80
48
        """
81
 
        # The detail is stored as the 'object' and the metadata as the info
82
 
        info=(summary,section)
83
49
        super(HelpTopicRegistry, self).register_lazy(topic, module_name,
84
 
                                                     member_name, info=info)
 
50
                                                     member_name, info=summary)
85
51
 
86
52
    def get_detail(self, topic):
87
53
        """Get the detailed help on a given topic."""
93
59
 
94
60
    def get_summary(self, topic):
95
61
        """Get the single line summary for the topic."""
96
 
        info = self.get_info(topic)
97
 
        if info is None:
98
 
            return None
99
 
        else:
100
 
            return info[0]
101
 
 
102
 
    def get_section(self, topic):
103
 
        """Get the section for the topic."""
104
 
        info = self.get_info(topic)
105
 
        if info is None:
106
 
            return None
107
 
        else:
108
 
            return info[1]
109
 
 
110
 
    def get_topics_for_section(self, section):
111
 
        """Get the set of topics in a section."""
112
 
        result = set()
113
 
        for topic in self.keys():
114
 
            if section == self.get_section(topic):
115
 
                result.add(topic)
116
 
        return result
 
62
        return self.get_info(topic)
117
63
 
118
64
 
119
65
topic_registry = HelpTopicRegistry()
126
72
 
127
73
    topics = topic_registry.keys()
128
74
    lmax = max(len(topic) for topic in topics)
129
 
 
 
75
        
130
76
    out = []
131
77
    for topic in topics:
132
78
        summary = topic_registry.get_summary(topic)
134
80
    return ''.join(out)
135
81
 
136
82
 
137
 
def _load_from_file(topic_name):
138
 
    """Load help from a file.
139
 
 
140
 
    Topics are expected to be txt files in bzrlib.help_topics.
141
 
    """
142
 
    resource_name = osutils.pathjoin("en", "%s.txt" % (topic_name,))
143
 
    return osutils.resource_string('bzrlib.help_topics', resource_name)
144
 
 
145
 
 
146
83
def _help_on_revisionspec(name):
147
 
    """Generate the help for revision specs."""
148
 
    import re
 
84
    """"Write the summary help for all documented topics to outfile."""
149
85
    import bzrlib.revisionspec
150
86
 
151
87
    out = []
152
 
    out.append(
153
 
"""Revision Identifiers
154
 
 
155
 
A revision identifier refers to a specific state of a branch's history.  It
156
 
can be expressed in several ways.  It can begin with a keyword to
157
 
unambiguously specify a given lookup type; some examples are 'last:1',
158
 
'before:yesterday' and 'submit:'.
159
 
 
160
 
Alternately, it can be given without a keyword, in which case it will be
161
 
checked as a revision number, a tag, a revision id, a date specification, or a
162
 
branch specification, in that order.  For example, 'date:today' could be
163
 
written as simply 'today', though if you have a tag called 'today' that will
164
 
be found first.
165
 
 
166
 
If 'REV1' and 'REV2' are revision identifiers, then 'REV1..REV2' denotes a
167
 
revision range. Examples: '3647..3649', 'date:yesterday..-1' and
168
 
'branch:/path/to/branch1/..branch:/branch2' (note that there are no quotes or
169
 
spaces around the '..').
170
 
 
171
 
Ranges are interpreted differently by different commands. To the "log" command,
172
 
a range is a sequence of log messages, but to the "diff" command, the range
173
 
denotes a change between revisions (and not a sequence of changes).  In
174
 
addition, "log" considers a closed range whereas "diff" and "merge" consider it
175
 
to be open-ended, that is, they include one end but not the other.  For example:
176
 
"bzr log -r 3647..3649" shows the messages of revisions 3647, 3648 and 3649,
177
 
while "bzr diff -r 3647..3649" includes the changes done in revisions 3648 and
178
 
3649, but not 3647.
179
 
 
180
 
The keywords used as revision selection methods are the following:
181
 
""")
182
 
    details = []
183
 
    details.append("\nIn addition, plugins can provide other keywords.")
184
 
    details.append("\nA detailed description of each keyword is given below.\n")
185
 
 
186
 
    # The help text is indented 4 spaces - this re cleans that up below
187
 
    indent_re = re.compile(r'^    ', re.MULTILINE)
188
 
    for prefix, i in bzrlib.revisionspec.revspec_registry.iteritems():
 
88
    out.append("\nRevision prefix specifier:"
 
89
               "\n--------------------------\n")
 
90
 
 
91
    for i in bzrlib.revisionspec.SPEC_TYPES:
189
92
        doc = i.help_txt
190
93
        if doc == bzrlib.revisionspec.RevisionSpec.help_txt:
191
 
            summary = "N/A"
192
 
            doc = summary + "\n"
193
 
        else:
194
 
            # Extract out the top line summary from the body and
195
 
            # clean-up the unwanted whitespace
196
 
            summary,doc = doc.split("\n", 1)
197
 
            #doc = indent_re.sub('', doc)
198
 
            while (doc[-2:] == '\n\n' or doc[-1:] == ' '):
199
 
                doc = doc[:-1]
200
 
 
201
 
        # Note: The leading : here are HACKs to get reStructuredText
202
 
        # 'field' formatting - we know that the prefix ends in a ':'.
203
 
        out.append(":%s\n\t%s" % (i.prefix, summary))
204
 
        details.append(":%s\n%s" % (i.prefix, doc))
205
 
 
206
 
    return '\n'.join(out + details)
207
 
 
208
 
 
209
 
def _help_on_transport(name):
210
 
    from bzrlib.transport import (
211
 
        transport_list_registry,
212
 
    )
213
 
    import textwrap
214
 
 
215
 
    def add_string(proto, help, maxl, prefix_width=20):
216
 
       help_lines = textwrap.wrap(help, maxl - prefix_width,
217
 
            break_long_words=False)
218
 
       line_with_indent = '\n' + ' ' * prefix_width
219
 
       help_text = line_with_indent.join(help_lines)
220
 
       return "%-20s%s\n" % (proto, help_text)
221
 
 
222
 
    def sort_func(a,b):
223
 
        a1 = a[:a.rfind("://")]
224
 
        b1 = b[:b.rfind("://")]
225
 
        if a1>b1:
226
 
            return +1
227
 
        elif a1<b1:
228
 
            return -1
229
 
        else:
230
 
            return 0
231
 
 
232
 
    protl = []
233
 
    decl = []
234
 
    protos = transport_list_registry.keys( )
235
 
    protos.sort(sort_func)
236
 
    for proto in protos:
237
 
        shorthelp = transport_list_registry.get_help(proto)
238
 
        if not shorthelp:
239
 
            continue
240
 
        if proto.endswith("://"):
241
 
            protl.append(add_string(proto, shorthelp, 79))
242
 
        else:
243
 
            decl.append(add_string(proto, shorthelp, 79))
244
 
 
245
 
 
246
 
    out = "URL Identifiers\n\n" + \
247
 
            "Supported URL prefixes::\n\n  " + \
248
 
            '  '.join(protl)
249
 
 
250
 
    if len(decl):
251
 
        out += "\nSupported modifiers::\n\n  " + \
252
 
            '  '.join(decl)
253
 
 
254
 
    out += """\
255
 
\nBazaar supports all of the standard parts within the URL::
256
 
 
257
 
  <protocol>://[user[:password]@]host[:port]/[path]
258
 
 
259
 
allowing URLs such as::
260
 
 
261
 
  http://bzruser:BadPass@bzr.example.com:8080/bzr/trunk
262
 
 
263
 
For bzr+ssh:// and sftp:// URLs, Bazaar also supports paths that begin
264
 
with '~' as meaning that the rest of the path should be interpreted
265
 
relative to the remote user's home directory.  For example if the user
266
 
``remote`` has a  home directory of ``/home/remote`` on the server
267
 
shell.example.com, then::
268
 
 
269
 
  bzr+ssh://remote@shell.example.com/~/myproject/trunk
270
 
 
271
 
would refer to ``/home/remote/myproject/trunk``.
272
 
"""
273
 
 
274
 
    return out
275
 
 
276
 
 
277
 
_basic_help = \
 
94
            doc = "N/A\n"
 
95
        while (doc[-2:] == '\n\n' or doc[-1:] == ' '):
 
96
            doc = doc[:-1]
 
97
 
 
98
        out.append("  %s %s\n\n" % (i.prefix, doc))
 
99
 
 
100
    return ''.join(out)
 
101
 
 
102
 
 
103
_basic_help= \
278
104
"""Bazaar -- a free distributed version-control tool
279
105
http://bazaar-vcs.org/
280
106
 
291
117
 
292
118
  bzr merge          pull in changes from another branch
293
119
  bzr commit         save some or all changes
294
 
  bzr send           send changes via email
295
120
 
296
121
  bzr log            show history of changes
297
122
  bzr check          validate storage
302
127
"""
303
128
 
304
129
 
305
 
_global_options = \
 
130
_global_options =\
306
131
"""Global Options
307
132
 
308
133
These options may be used with any command, and may appear in front of any
309
 
command.  (e.g. ``bzr --profile help``).
310
 
 
311
 
--version      Print the version number. Must be supplied before the command.
312
 
--no-aliases   Do not process command aliases when running this command.
 
134
command.  (e.g. "bzr --quiet help").
 
135
 
 
136
--quiet        Suppress informational output; only print errors and warnings
 
137
--version      Print the version number
 
138
 
 
139
--no-aliases   Do not process command aliases when running this command
313
140
--builtin      Use the built-in version of a command, not the plugin version.
314
 
               This does not suppress other plugin effects.
315
 
--no-plugins   Do not process any plugins.
316
 
--concurrency  Number of processes that can be run concurrently (selftest).
 
141
               This does not suppress other plugin effects
 
142
--no-plugins   Do not process any plugins
317
143
 
318
 
--profile      Profile execution using the hotshot profiler.
319
 
--lsprof       Profile execution using the lsprof profiler.
 
144
-Derror        Instead of normal error handling, always print a traceback on
 
145
               error.
 
146
--profile      Profile execution using the hotshot profiler
 
147
--lsprof       Profile execution using the lsprof profiler
320
148
--lsprof-file  Profile execution using the lsprof profiler, and write the
321
 
               results to a specified file.  If the filename ends with ".txt",
322
 
               text format will be used.  If the filename either starts with
323
 
               "callgrind.out" or end with ".callgrind", the output will be
324
 
               formatted for use with KCacheGrind. Otherwise, the output
325
 
               will be a pickle.
326
 
--coverage     Generate line coverage report in the specified directory.
327
 
 
328
 
See http://doc.bazaar.canonical.com/developers/profiling.html for more
329
 
information on profiling.
330
 
 
331
 
A number of debug flags are also available to assist troubleshooting and
332
 
development.  See :doc:`debug-flags-help`.
333
 
"""
334
 
 
335
 
_standard_options = \
336
 
"""Standard Options
337
 
 
338
 
Standard options are legal for all commands.
339
 
 
340
 
--help, -h     Show help message.
341
 
--verbose, -v  Display more information.
342
 
--quiet, -q    Only display errors and warnings.
343
 
 
344
 
Unlike global options, standard options can be used in aliases.
345
 
"""
346
 
 
 
149
               results to a specified file.
 
150
 
 
151
Note: --version must be supplied before any command.
 
152
"""
347
153
 
348
154
_checkouts = \
349
155
"""Checkouts
384
190
branch, which could be slow if a network connection is involved. Also, as you
385
191
don't have a local branch, then you cannot commit locally.
386
192
 
387
 
Lightweight checkouts work best when you have fast reliable access to the
 
193
Lightwieght checkouts work best when you have fast reliable access to the
388
194
master branch. This means that if the master branch is on the same disk or LAN
389
195
a lightweight checkout will be faster than a heavyweight one for any commands
390
 
that modify the revision history (as only one copy of the branch needs to
391
 
be updated). Heavyweight checkouts will generally be faster for any command
392
 
that uses the history but does not change it, but if the master branch is on
393
 
the same disk then there won't be a noticeable difference.
 
196
that modify the revision history (as only one copy branch needs to be updated).
 
197
Heavyweight checkouts will generally be faster for any command that uses the
 
198
history but does not change it, but if the master branch is on the same disk
 
199
then there wont be a noticeable difference.
394
200
 
395
201
Another possible use for a checkout is to use it with a treeless repository
396
 
containing your branches, where you maintain only one working tree by
397
 
switching the master branch that the checkout points to when you want to
 
202
containing your branches, where you maintain only only one working tree by
 
203
switching the master branch that the checkout points to when you want to 
398
204
work on a different branch.
399
205
 
400
206
Obviously to commit on a checkout you need to be able to write to the master
401
 
branch. This means that the master branch must be accessible over a writeable
 
207
branch. This means that the master branch must be accessable over a writeable
402
208
protocol , such as sftp://, and that you have write permissions at the other
403
209
end. Checkouts also work on the local file system, so that all that matters is
404
210
file permissions.
407
213
bind"). This will change the location that the commits are sent to. The bind
408
214
command can also be used to turn a branch into a heavy checkout. If you
409
215
would like to convert your heavy checkout into a normal branch so that every
410
 
commit is local, you can use the "unbind" command. To see whether or not a
411
 
branch is bound or not you can use the "info" command. If the branch is bound
412
 
it will tell you the location of the bound branch.
 
216
commit is local, you can use the "unbind" command.
413
217
 
414
 
Related commands::
 
218
Related commands:
415
219
 
416
220
  checkout    Create a checkout. Pass --lightweight to get a lightweight
417
221
              checkout
418
222
  update      Pull any changes in the master branch in to your checkout
419
223
  commit      Make a commit that is sent to the master branch. If you have
420
 
              a heavy checkout then the --local option will commit to the
 
224
              a heavy checkout then the --local option will commit to the 
421
225
              checkout without sending the commit to the master
422
226
  bind        Change the master branch that the commits in the checkout will
423
227
              be sent to
424
228
  unbind      Turn a heavy checkout into a standalone branch so that any
425
229
              commits are only made locally
426
 
  info        Displays whether a branch is bound or unbound. If the branch is
427
 
              bound, then it will also display the location of the bound branch
428
 
"""
429
 
 
430
 
_repositories = \
431
 
"""Repositories
432
 
 
433
 
Repositories in Bazaar are where committed information is stored. There is
434
 
a repository associated with every branch.
435
 
 
436
 
Repositories are a form of database. Bzr will usually maintain this for
437
 
good performance automatically, but in some situations (e.g. when doing
438
 
very many commits in a short time period) you may want to ask bzr to
439
 
optimise the database indices. This can be done by the 'bzr pack' command.
440
 
 
441
 
By default just running 'bzr init' will create a repository within the new
442
 
branch but it is possible to create a shared repository which allows multiple
443
 
branches to share their information in the same location. When a new branch is
444
 
created it will first look to see if there is a containing shared repository it
445
 
can use.
446
 
 
447
 
When two branches of the same project share a repository, there is
448
 
generally a large space saving. For some operations (e.g. branching
449
 
within the repository) this translates in to a large time saving.
450
 
 
451
 
To create a shared repository use the init-repository command (or the alias
452
 
init-repo). This command takes the location of the repository to create. This
453
 
means that 'bzr init-repository repo' will create a directory named 'repo',
454
 
which contains a shared repository. Any new branches that are created in this
455
 
directory will then use it for storage.
456
 
 
457
 
It is a good idea to create a repository whenever you might create more
458
 
than one branch of a project. This is true for both working areas where you
459
 
are doing the development, and any server areas that you use for hosting
460
 
projects. In the latter case, it is common to want branches without working
461
 
trees. Since the files in the branch will not be edited directly there is no
462
 
need to use up disk space for a working tree. To create a repository in which
463
 
the branches will not have working trees pass the '--no-trees' option to
464
 
'init-repository'.
465
 
 
466
 
Related commands::
467
 
 
468
 
  init-repository   Create a shared repository. Use --no-trees to create one
469
 
                    in which new branches won't get a working tree.
470
 
"""
471
 
 
472
 
 
473
 
_working_trees = \
474
 
"""Working Trees
475
 
 
476
 
A working tree is the contents of a branch placed on disk so that you can
477
 
see the files and edit them. The working tree is where you make changes to a
478
 
branch, and when you commit the current state of the working tree is the
479
 
snapshot that is recorded in the commit.
480
 
 
481
 
When you push a branch to a remote system, a working tree will not be
482
 
created. If one is already present the files will not be updated. The
483
 
branch information will be updated and the working tree will be marked
484
 
as out-of-date. Updating a working tree remotely is difficult, as there
485
 
may be uncommitted changes or the update may cause content conflicts that are
486
 
difficult to deal with remotely.
487
 
 
488
 
If you have a branch with no working tree you can use the 'checkout' command
489
 
to create a working tree. If you run 'bzr checkout .' from the branch it will
490
 
create the working tree. If the branch is updated remotely, you can update the
491
 
working tree by running 'bzr update' in that directory.
492
 
 
493
 
If you have a branch with a working tree that you do not want the 'remove-tree'
494
 
command will remove the tree if it is safe. This can be done to avoid the
495
 
warning about the remote working tree not being updated when pushing to the
496
 
branch. It can also be useful when working with a '--no-trees' repository
497
 
(see 'bzr help repositories').
498
 
 
499
 
If you want to have a working tree on a remote machine that you push to you
500
 
can either run 'bzr update' in the remote branch after each push, or use some
501
 
other method to update the tree during the push. There is an 'rspush' plugin
502
 
that will update the working tree using rsync as well as doing a push. There
503
 
is also a 'push-and-update' plugin that automates running 'bzr update' via SSH
504
 
after each push.
505
 
 
506
 
Useful commands::
507
 
 
508
 
  checkout     Create a working tree when a branch does not have one.
509
 
  remove-tree  Removes the working tree from a branch when it is safe to do so.
510
 
  update       When a working tree is out of sync with it's associated branch
511
 
               this will update the tree to match the branch.
512
 
"""
513
 
 
514
 
 
515
 
_branches = \
516
 
"""Branches
517
 
 
518
 
A branch consists of the state of a project, including all of its
519
 
history. All branches have a repository associated (which is where the
520
 
branch history is stored), but multiple branches may share the same
521
 
repository (a shared repository). Branches can be copied and merged.
522
 
 
523
 
Related commands::
524
 
 
525
 
  init    Change a directory into a versioned branch.
526
 
  branch  Create a new branch that is a copy of an existing branch.
527
 
  merge   Perform a three-way merge.
528
 
"""
529
 
 
530
 
 
531
 
_standalone_trees = \
532
 
"""Standalone Trees
533
 
 
534
 
A standalone tree is a working tree with an associated repository. It
535
 
is an independently usable branch, with no dependencies on any other.
536
 
Creating a standalone tree (via bzr init) is the quickest way to put
537
 
an existing project under version control.
538
 
 
539
 
Related Commands::
540
 
 
541
 
  init    Make a directory into a versioned branch.
542
 
"""
543
 
 
544
 
 
545
 
_status_flags = \
546
 
"""Status Flags
547
 
 
548
 
Status flags are used to summarise changes to the working tree in a concise
549
 
manner.  They are in the form::
550
 
 
551
 
   xxx   <filename>
552
 
 
553
 
where the columns' meanings are as follows.
554
 
 
555
 
Column 1 - versioning/renames::
556
 
 
557
 
  + File versioned
558
 
  - File unversioned
559
 
  R File renamed
560
 
  ? File unknown
561
 
  X File nonexistent (and unknown to bzr)
562
 
  C File has conflicts
563
 
  P Entry for a pending merge (not a file)
564
 
 
565
 
Column 2 - contents::
566
 
 
567
 
  N File created
568
 
  D File deleted
569
 
  K File kind changed
570
 
  M File modified
571
 
 
572
 
Column 3 - execute::
573
 
 
574
 
  * The execute bit was changed
575
 
"""
576
 
 
577
 
 
578
 
_env_variables = \
579
 
"""Environment Variables
580
 
 
581
 
================ =================================================================
582
 
BZRPATH          Path where bzr is to look for shell plugin external commands.
583
 
BZR_EMAIL        E-Mail address of the user. Overrides EMAIL.
584
 
EMAIL            E-Mail address of the user.
585
 
BZR_EDITOR       Editor for editing commit messages. Overrides EDITOR.
586
 
EDITOR           Editor for editing commit messages.
587
 
BZR_PLUGIN_PATH  Paths where bzr should look for plugins.
588
 
BZR_HOME         Directory holding .bazaar config dir. Overrides HOME.
589
 
BZR_HOME (Win32) Directory holding bazaar config dir. Overrides APPDATA and HOME.
590
 
BZR_REMOTE_PATH  Full name of remote 'bzr' command (for bzr+ssh:// URLs).
591
 
BZR_SSH          Path to SSH client, or one of paramiko, openssh, sshcorp, plink.
592
 
BZR_LOG          Location of .bzr.log (use '/dev/null' to suppress log).
593
 
BZR_LOG (Win32)  Location of .bzr.log (use 'NUL' to suppress log).
594
 
BZR_COLUMNS      Override implicit terminal width.
595
 
BZR_CONCURRENCY  Number of processes that can be run concurrently (selftest).
596
 
================ =================================================================
597
 
"""
598
 
 
599
 
 
600
 
_files = \
601
 
r"""Files
602
 
 
603
 
:On Linux:   ~/.bazaar/bazaar.conf
604
 
:On Windows: C:\\Documents and Settings\\username\\Application Data\\bazaar\\2.0\\bazaar.conf
605
 
 
606
 
Contains the user's default configuration. The section ``[DEFAULT]`` is
607
 
used to define general configuration that will be applied everywhere.
608
 
The section ``[ALIASES]`` can be used to create command aliases for
609
 
commonly used options.
610
 
 
611
 
A typical config file might look something like::
612
 
 
613
 
  [DEFAULT]
614
 
  email=John Doe <jdoe@isp.com>
615
 
 
616
 
  [ALIASES]
617
 
  commit = commit --strict
618
 
  log10 = log --short -r -10..-1
619
 
"""
620
 
 
621
 
_criss_cross = \
622
 
"""Criss-Cross
623
 
 
624
 
A criss-cross in the branch history can cause the default merge technique
625
 
to emit more conflicts than would normally be expected.
626
 
 
627
 
In complex merge cases, ``bzr merge --lca`` or ``bzr merge --weave`` may give
628
 
better results.  You may wish to ``bzr revert`` the working tree and merge
629
 
again.  Alternatively, use ``bzr remerge`` on particular conflicted files.
630
 
 
631
 
Criss-crosses occur in a branch's history if two branches merge the same thing
632
 
and then merge one another, or if two branches merge one another at the same
633
 
time.  They can be avoided by having each branch only merge from or into a
634
 
designated central branch (a "star topology").
635
 
 
636
 
Criss-crosses cause problems because of the way merge works.  Bazaar's default
637
 
merge is a three-way merger; in order to merge OTHER into THIS, it must
638
 
find a basis for comparison, BASE.  Using BASE, it can determine whether
639
 
differences between THIS and OTHER are due to one side adding lines, or
640
 
from another side removing lines.
641
 
 
642
 
Criss-crosses mean there is no good choice for a base.  Selecting the recent
643
 
merge points could cause one side's changes to be silently discarded.
644
 
Selecting older merge points (which Bazaar does) mean that extra conflicts
645
 
are emitted.
646
 
 
647
 
The ``weave`` merge type is not affected by this problem because it uses
648
 
line-origin detection instead of a basis revision to determine the cause of
649
 
differences.
650
 
"""
651
 
 
652
 
_branches_out_of_sync = """Branches Out of Sync
653
 
 
654
 
When reconfiguring a checkout, tree or branch into a lightweight checkout,
655
 
a local branch must be destroyed.  (For checkouts, this is the local branch
656
 
that serves primarily as a cache.)  If the branch-to-be-destroyed does not
657
 
have the same last revision as the new reference branch for the lightweight
658
 
checkout, data could be lost, so Bazaar refuses.
659
 
 
660
 
How you deal with this depends on *why* the branches are out of sync.
661
 
 
662
 
If you have a checkout and have done local commits, you can get back in sync
663
 
by running "bzr update" (and possibly "bzr commit").
664
 
 
665
 
If you have a branch and the remote branch is out-of-date, you can push
666
 
the local changes using "bzr push".  If the local branch is out of date, you
667
 
can do "bzr pull".  If both branches have had changes, you can merge, commit
668
 
and then push your changes.  If you decide that some of the changes aren't
669
 
useful, you can "push --overwrite" or "pull --overwrite" instead.
670
 
"""
671
 
 
672
 
 
673
 
_storage_formats = \
674
 
"""Storage Formats
675
 
 
676
 
To ensure that older clients do not access data incorrectly,
677
 
Bazaar's policy is to introduce a new storage format whenever
678
 
new features requiring new metadata are added. New storage
679
 
formats may also be introduced to improve performance and
680
 
scalability.
681
 
 
682
 
The newest format, 2a, is highly recommended. If your
683
 
project is not using 2a, then you should suggest to the
684
 
project owner to upgrade.
685
 
 
686
 
 
687
 
.. note::
688
 
 
689
 
   Some of the older formats have two variants:
690
 
   a plain one and a rich-root one. The latter include an additional
691
 
   field about the root of the tree. There is no performance cost
692
 
   for using a rich-root format but you cannot easily merge changes
693
 
   from a rich-root format into a plain format. As a consequence,
694
 
   moving a project to a rich-root format takes some co-ordination
695
 
   in that all contributors need to upgrade their repositories
696
 
   around the same time. 2a and all future formats will be
697
 
   implicitly rich-root.
698
 
 
699
 
See :doc:`current-formats-help` for the complete list of
700
 
currently supported formats. See :doc:`other-formats-help` for
701
 
descriptions of any available experimental and deprecated formats.
702
 
"""
703
 
 
704
 
 
705
 
# Register help topics
 
230
"""
 
231
 
 
232
 
706
233
topic_registry.register("revisionspec", _help_on_revisionspec,
707
234
                        "Explain how to use --revision")
708
 
topic_registry.register('basic', _basic_help, "Basic commands", SECT_HIDDEN)
709
 
topic_registry.register('topics', _help_on_topics, "Topics list", SECT_HIDDEN)
710
 
def get_current_formats_topic(topic):
711
 
    from bzrlib import bzrdir
712
 
    return "Current Storage Formats\n\n" + \
713
 
        bzrdir.format_registry.help_topic(topic)
714
 
def get_other_formats_topic(topic):
715
 
    from bzrlib import bzrdir
716
 
    return "Other Storage Formats\n\n" + \
717
 
        bzrdir.format_registry.help_topic(topic)
718
 
topic_registry.register('current-formats', get_current_formats_topic,
719
 
    'Current storage formats')
720
 
topic_registry.register('other-formats', get_other_formats_topic,
721
 
    'Experimental and deprecated storage formats')
722
 
topic_registry.register('standard-options', _standard_options,
 
235
topic_registry.register('basic', _basic_help, "Basic commands")
 
236
topic_registry.register('topics', _help_on_topics, "Topics list")
 
237
def get_format_topic(topic):
 
238
    from bzrlib import bzrdir
 
239
    return bzrdir.format_registry.help_topic(topic)
 
240
topic_registry.register('formats', get_format_topic, 'Directory formats')
 
241
topic_registry.register('global-options', _global_options,
723
242
                        'Options that can be used with any command')
724
 
topic_registry.register('global-options', _global_options,
725
 
                    'Options that control how Bazaar runs')
726
 
topic_registry.register('urlspec', _help_on_transport,
727
 
                        "Supported transport protocols")
728
 
topic_registry.register('status-flags', _status_flags,
729
 
                        "Help on status flags")
730
 
def get_bugs_topic(topic):
731
 
    from bzrlib import bugtracker
732
 
    return ("Bug Tracker Settings\n\n" +
733
 
        bugtracker.tracker_registry.help_topic(topic))
734
 
topic_registry.register('bugs', get_bugs_topic, 'Bug tracker settings')
735
 
topic_registry.register('env-variables', _env_variables,
736
 
                        'Environment variable names and values')
737
 
topic_registry.register('files', _files,
738
 
                        'Information on configuration and log files')
739
 
topic_registry.register_lazy('hooks', 'bzrlib.hooks', 'hooks_help_text',
740
 
                        'Points at which custom processing can be added')
741
 
 
742
 
# Load some of the help topics from files. Note that topics which reproduce API
743
 
# details will tend to skew (quickly usually!) so please seek other solutions
744
 
# for such things.
745
 
topic_registry.register('authentication', _load_from_file,
746
 
                        'Information on configuring authentication')
747
 
topic_registry.register('configuration', _load_from_file,
748
 
                        'Details on the configuration settings available')
749
 
topic_registry.register('conflict-types', _load_from_file,
750
 
                        'Types of conflicts and what to do about them')
751
 
topic_registry.register('debug-flags', _load_from_file,
752
 
                        'Options to show or record debug information')
753
 
topic_registry.register('log-formats', _load_from_file,
754
 
                        'Details on the logging formats available')
755
 
 
756
 
 
757
 
# Register concept topics.
758
 
# Note that we might choose to remove these from the online help in the
759
 
# future or implement them via loading content from files. In the meantime,
760
 
# please keep them concise.
761
 
topic_registry.register('branches', _branches,
762
 
                        'Information on what a branch is', SECT_CONCEPT)
763
243
topic_registry.register('checkouts', _checkouts,
764
 
                        'Information on what a checkout is', SECT_CONCEPT)
765
 
topic_registry.register('content-filters', _load_from_file,
766
 
                        'Conversion of content into/from working trees',
767
 
                        SECT_CONCEPT)
768
 
topic_registry.register('diverged-branches', _load_from_file,
769
 
                        'How to fix diverged branches',
770
 
                        SECT_CONCEPT)
771
 
topic_registry.register('eol', _load_from_file,
772
 
                        'Information on end-of-line handling',
773
 
                        SECT_CONCEPT)
774
 
topic_registry.register('formats', _storage_formats,
775
 
                        'Information on choosing a storage format',
776
 
                        SECT_CONCEPT)
777
 
topic_registry.register('patterns', _load_from_file,
778
 
                        'Information on the pattern syntax',
779
 
                        SECT_CONCEPT)
780
 
topic_registry.register('repositories', _repositories,
781
 
                        'Basic information on shared repositories.',
782
 
                        SECT_CONCEPT)
783
 
topic_registry.register('rules', _load_from_file,
784
 
                        'Information on defining rule-based preferences',
785
 
                        SECT_CONCEPT)
786
 
topic_registry.register('standalone-trees', _standalone_trees,
787
 
                        'Information on what a standalone tree is',
788
 
                        SECT_CONCEPT)
789
 
topic_registry.register('working-trees', _working_trees,
790
 
                        'Information on working trees', SECT_CONCEPT)
791
 
topic_registry.register('criss-cross', _criss_cross,
792
 
                        'Information on criss-cross merging', SECT_CONCEPT)
793
 
topic_registry.register('sync-for-reconfigure', _branches_out_of_sync,
794
 
                        'Steps to resolve "out-of-sync" when reconfiguring',
795
 
                        SECT_CONCEPT)
796
 
 
797
 
 
798
 
class HelpTopicIndex(object):
799
 
    """A index for bzr help that returns topics."""
800
 
 
801
 
    def __init__(self):
802
 
        self.prefix = ''
803
 
 
804
 
    def get_topics(self, topic):
805
 
        """Search for topic in the HelpTopicRegistry.
806
 
 
807
 
        :param topic: A topic to search for. None is treated as 'basic'.
808
 
        :return: A list which is either empty or contains a single
809
 
            RegisteredTopic entry.
810
 
        """
811
 
        if topic is None:
812
 
            topic = 'basic'
813
 
        if topic in topic_registry:
814
 
            return [RegisteredTopic(topic)]
815
 
        else:
816
 
            return []
817
 
 
818
 
 
819
 
class RegisteredTopic(object):
820
 
    """A help topic which has been registered in the HelpTopicRegistry.
821
 
 
822
 
    These topics consist of nothing more than the name of the topic - all
823
 
    data is retrieved on demand from the registry.
824
 
    """
825
 
 
826
 
    def __init__(self, topic):
827
 
        """Constructor.
828
 
 
829
 
        :param topic: The name of the topic that this represents.
830
 
        """
831
 
        self.topic = topic
832
 
 
833
 
    def get_help_text(self, additional_see_also=None, plain=True):
834
 
        """Return a string with the help for this topic.
835
 
 
836
 
        :param additional_see_also: Additional help topics to be
837
 
            cross-referenced.
838
 
        :param plain: if False, raw help (reStructuredText) is
839
 
            returned instead of plain text.
840
 
        """
841
 
        result = topic_registry.get_detail(self.topic)
842
 
        # there is code duplicated here and in bzrlib/plugin.py's
843
 
        # matching Topic code. This should probably be factored in
844
 
        # to a helper function and a common base class.
845
 
        if additional_see_also is not None:
846
 
            see_also = sorted(set(additional_see_also))
847
 
        else:
848
 
            see_also = None
849
 
        if see_also:
850
 
            result += '\n:See also: '
851
 
            result += ', '.join(see_also)
852
 
            result += '\n'
853
 
        if plain:
854
 
            result = help_as_plain_text(result)
855
 
        return result
856
 
 
857
 
    def get_help_topic(self):
858
 
        """Return the help topic this can be found under."""
859
 
        return self.topic
860
 
 
861
 
 
862
 
def help_as_plain_text(text):
863
 
    """Minimal converter of reStructuredText to plain text."""
864
 
    import re
865
 
    lines = text.splitlines()
866
 
    result = []
867
 
    for line in lines:
868
 
        if line.startswith(':'):
869
 
            line = line[1:]
870
 
        elif line.endswith('::'):
871
 
            line = line[:-1]
872
 
        # Map :doc:`xxx-help` to ``bzr help xxx``
873
 
        line = re.sub(":doc:`(.+)-help`", r'``bzr help \1``', line)
874
 
        result.append(line)
875
 
    return "\n".join(result) + "\n"
 
244
                        'Information on what a checkout is')
 
245