277
277
A number of debug flags are also available to assist troubleshooting and
280
-Dauth Trace authentication sections used.
281
-Derror Instead of normal error handling, always print a traceback on
283
-Devil Capture call sites that do expensive or badly-scaling
285
-Dfetch Trace history copying between repositories.
286
-Dhashcache Log every time a working file is read to determine its hash.
287
-Dhooks Trace hook execution.
288
-Dhpss Trace smart protocol requests and responses.
289
-Dhttp Trace http connections, requests and responses
290
-Dindex Trace major index operations.
291
-Dknit Trace knit operations.
292
-Dlock Trace when lockdir locks are taken or released.
293
-Dmerge Emit information for debugging merges.
294
-Dpack Emit information about pack operations.
280
-Dauth Trace authentication sections used.
281
-Derror Instead of normal error handling, always print a traceback
283
-Devil Capture call sites that do expensive or badly-scaling
285
-Dfetch Trace history copying between repositories.
286
-Dhashcache Log every time a working file is read to determine its hash.
287
-Dhooks Trace hook execution.
288
-Dhpss Trace smart protocol requests and responses.
289
-Dhttp Trace http connections, requests and responses
290
-Dindex Trace major index operations.
291
-Dknit Trace knit operations.
292
-Dlock Trace when lockdir locks are taken or released.
293
-Dmerge Emit information for debugging merges.
294
-Dpack Emit information about pack operations.
297
297
_standard_options = \
349
349
Lightweight checkouts work best when you have fast reliable access to the
350
350
master branch. This means that if the master branch is on the same disk or LAN
351
351
a lightweight checkout will be faster than a heavyweight one for any commands
352
that modify the revision history (as only one copy branch needs to be updated).
353
Heavyweight checkouts will generally be faster for any command that uses the
354
history but does not change it, but if the master branch is on the same disk
355
then there wont be a noticeable difference.
352
that modify the revision history (as only one copy of the branch needs to
353
be updated). Heavyweight checkouts will generally be faster for any command
354
that uses the history but does not change it, but if the master branch is on
355
the same disk then there won't be a noticeable difference.
357
357
Another possible use for a checkout is to use it with a treeless repository
358
358
containing your branches, where you maintain only one working tree by
579
579
A criss-cross in the branch history can cause the default merge technique
580
580
to emit more conflicts than would normally be expected.
582
If you encounter criss-crosses, you can use merge --weave instead, which
583
should provide a much better result.
582
In complex merge cases, ``bzr merge --lca`` or ``bzr merge --weave`` may give
583
better results. You may wish to ``bzr revert`` the working tree and merge
584
again. Alternatively, use ``bzr remerge`` on particular conflicted files.
585
586
Criss-crosses occur in a branch's history if two branches merge the same thing
586
587
and then merge one another, or if two branches merge one another at the same
601
602
The ``weave`` merge type is not affected by this problem because it uses
602
603
line-origin detection instead of a basis revision to determine the cause of
607
_branches_out_of_sync = """Branches out of sync
609
When reconfiguring a checkout, tree or branch into a lightweight checkout,
610
a local branch must be destroyed. (For checkouts, this is the local branch
611
that serves primarily as a cache.) If the branch-to-be-destroyed does not
612
have the same last revision as the new reference branch for the lightweight
613
checkout, data could be lost, so Bazaar refuses.
615
How you deal with this depends on *why* the branches are out of sync.
617
If you have a checkout and have done local commits, you can get back in sync
618
by running "bzr update" (and possibly "bzr commit").
620
If you have a branch and the remote branch is out-of-date, you can push
621
the local changes using "bzr push". If the local branch is out of date, you
622
can do "bzr pull". If both branches have had changes, you can merge, commit
623
and then push your changes. If you decide that some of the changes aren't
624
useful, you can "push --overwrite" or "pull --overwrite" instead.
606
628
# Register help topics
649
671
'Information on what a branch is', SECT_CONCEPT)
650
672
topic_registry.register('checkouts', _checkouts,
651
673
'Information on what a checkout is', SECT_CONCEPT)
674
topic_registry.register('patterns', _load_from_file,
675
'Information on the pattern syntax',
652
677
topic_registry.register('repositories', _repositories,
653
678
'Basic information on shared repositories.',
680
topic_registry.register('rules', _load_from_file,
681
'Information on defining rule-based preferences',
655
683
topic_registry.register('standalone-trees', _standalone_trees,
656
684
'Information on what a standalone tree is',
659
687
'Information on working trees', SECT_CONCEPT)
660
688
topic_registry.register('criss-cross', _criss_cross,
661
689
'Information on criss-cross merging', SECT_CONCEPT)
690
topic_registry.register('sync-for-reconfigure', _branches_out_of_sync,
691
'Information on criss-cross merging', SECT_CONCEPT)
664
694
class HelpTopicIndex(object):
added
removed
bzrlib/help_topics/__init__.py
