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.
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.
296
297
_standard_options = \
348
349
Lightweight checkouts work best when you have fast reliable access to the
349
350
master branch. This means that if the master branch is on the same disk or LAN
350
351
a lightweight checkout will be faster than a heavyweight one for any commands
351
that modify the revision history (as only one copy branch needs to be updated).
352
Heavyweight checkouts will generally be faster for any command that uses the
353
history but does not change it, but if the master branch is on the same disk
354
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.
356
357
Another possible use for a checkout is to use it with a treeless repository
357
358
containing your branches, where you maintain only one working tree by
578
579
A criss-cross in the branch history can cause the default merge technique
579
580
to emit more conflicts than would normally be expected.
581
If you encounter criss-crosses, you can use merge --weave instead, which
582
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.
584
586
Criss-crosses occur in a branch's history if two branches merge the same thing
585
587
and then merge one another, or if two branches merge one another at the same
600
602
The ``weave`` merge type is not affected by this problem because it uses
601
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.
605
628
# Register help topics
658
681
'Information on working trees', SECT_CONCEPT)
659
682
topic_registry.register('criss-cross', _criss_cross,
660
683
'Information on criss-cross merging', SECT_CONCEPT)
684
topic_registry.register('sync-for-reconfigure', _branches_out_of_sync,
685
'Information on criss-cross merging', SECT_CONCEPT)
663
688
class HelpTopicIndex(object):
added
removed
bzrlib/help_topics/__init__.py
