Tarball conversion

13 files changed, 2914 insertions, 0 deletions

diff --git a/bzrlib/help_topics/__init__.py b/bzrlib/help_topics/__init__.py
new file mode 100644
index 0000000..ef1d8e9
--- /dev/null
+++ b/bzrlib/help_topics/__init__.py
@@ -0,0 +1,943 @@
+# Copyright (C) 2006-2011 Canonical Ltd
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+
+"""A collection of extra help information for using bzr.
+
+Help topics are meant to be help for items that aren't commands, but will
+help bzr become fully learnable without referring to a tutorial.
+
+Limited formatting of help text is permitted to make the text useful
+both within the reference manual (reStructuredText) and on the screen.
+The help text should be reStructuredText with formatting kept to a
+minimum and, in particular, no headings. The onscreen renderer applies
+the following simple rules before rendering the text:
+
+    1. A '::' appearing on the end of a line is replaced with ':'.
+    2. Lines starting with a ':' have it stripped.
+
+These rules mean that literal blocks and field lists respectively can
+be used in the help text, producing sensible input to a manual while
+rendering on the screen naturally.
+"""
+
+from __future__ import absolute_import
+
+import bzrlib
+from bzrlib import (
+    config,
+    osutils,
+    registry,
+    i18n,
+    )
+
+
+# Section identifiers (map topics to the right place in the manual)
+SECT_COMMAND = "command"
+SECT_CONCEPT = "concept"
+SECT_HIDDEN =  "hidden"
+SECT_LIST    = "list"
+SECT_PLUGIN  = "plugin"
+
+
+class HelpTopicRegistry(registry.Registry):
+    """A Registry customized for handling help topics."""
+
+    def register(self, topic, detail, summary, section=SECT_LIST):
+        """Register a new help topic.
+
+        :param topic: Name of documentation entry
+        :param detail: Function or string object providing detailed
+            documentation for topic.  Function interface is detail(topic).
+            This should return a text string of the detailed information.
+            See the module documentation for details on help text formatting.
+        :param summary: String providing single-line documentation for topic.
+        :param section: Section in reference manual - see SECT_* identifiers.
+        """
+        # The detail is stored as the 'object' and the metadata as the info
+        info = (summary, section)
+        super(HelpTopicRegistry, self).register(topic, detail, info=info)
+
+    def register_lazy(self, topic, module_name, member_name, summary,
+                      section=SECT_LIST):
+        """Register a new help topic, and import the details on demand.
+
+        :param topic: Name of documentation entry
+        :param module_name: The module to find the detailed help.
+        :param member_name: The member of the module to use for detailed help.
+        :param summary: String providing single-line documentation for topic.
+        :param section: Section in reference manual - see SECT_* identifiers.
+        """
+        # The detail is stored as the 'object' and the metadata as the info
+        info = (summary, section)
+        super(HelpTopicRegistry, self).register_lazy(topic, module_name,
+                                                     member_name, info=info)
+
+    def get_detail(self, topic):
+        """Get the detailed help on a given topic."""
+        obj = self.get(topic)
+        if callable(obj):
+            return obj(topic)
+        else:
+            return obj
+
+    def get_summary(self, topic):
+        """Get the single line summary for the topic."""
+        info = self.get_info(topic)
+        if info is None:
+            return None
+        else:
+            return info[0]
+
+    def get_section(self, topic):
+        """Get the section for the topic."""
+        info = self.get_info(topic)
+        if info is None:
+            return None
+        else:
+            return info[1]
+
+    def get_topics_for_section(self, section):
+        """Get the set of topics in a section."""
+        result = set()
+        for topic in self.keys():
+            if section == self.get_section(topic):
+                result.add(topic)
+        return result
+
+
+topic_registry = HelpTopicRegistry()
+
+
+#----------------------------------------------------
+
+def _help_on_topics(dummy):
+    """Write out the help for topics to outfile"""
+
+    topics = topic_registry.keys()
+    lmax = max(len(topic) for topic in topics)
+
+    out = []
+    for topic in topics:
+        summary = topic_registry.get_summary(topic)
+        out.append("%-*s %s\n" % (lmax, topic, summary))
+    return ''.join(out)
+
+
+def _load_from_file(topic_name):
+    """Load help from a file.
+
+    Topics are expected to be txt files in bzrlib.help_topics.
+    """
+    resource_name = osutils.pathjoin("en", "%s.txt" % (topic_name,))
+    return osutils.resource_string('bzrlib.help_topics', resource_name)
+
+
+def _help_on_revisionspec(name):
+    """Generate the help for revision specs."""
+    import re
+    import bzrlib.revisionspec
+
+    out = []
+    out.append(
+"""Revision Identifiers
+
+A revision identifier refers to a specific state of a branch's history.  It
+can be expressed in several ways.  It can begin with a keyword to
+unambiguously specify a given lookup type; some examples are 'last:1',
+'before:yesterday' and 'submit:'.
+
+Alternately, it can be given without a keyword, in which case it will be
+checked as a revision number, a tag, a revision id, a date specification, or a
+branch specification, in that order.  For example, 'date:today' could be
+written as simply 'today', though if you have a tag called 'today' that will
+be found first.
+
+If 'REV1' and 'REV2' are revision identifiers, then 'REV1..REV2' denotes a
+revision range. Examples: '3647..3649', 'date:yesterday..-1' and
+'branch:/path/to/branch1/..branch:/branch2' (note that there are no quotes or
+spaces around the '..').
+
+Ranges are interpreted differently by different commands. To the "log" command,
+a range is a sequence of log messages, but to the "diff" command, the range
+denotes a change between revisions (and not a sequence of changes).  In
+addition, "log" considers a closed range whereas "diff" and "merge" consider it
+to be open-ended, that is, they include one end but not the other.  For example:
+"bzr log -r 3647..3649" shows the messages of revisions 3647, 3648 and 3649,
+while "bzr diff -r 3647..3649" includes the changes done in revisions 3648 and
+3649, but not 3647.
+
+The keywords used as revision selection methods are the following:
+""")
+    details = []
+    details.append("\nIn addition, plugins can provide other keywords.")
+    details.append("\nA detailed description of each keyword is given below.\n")
+
+    # The help text is indented 4 spaces - this re cleans that up below
+    indent_re = re.compile(r'^    ', re.MULTILINE)
+    for prefix, i in bzrlib.revisionspec.revspec_registry.iteritems():
+        doc = i.help_txt
+        if doc == bzrlib.revisionspec.RevisionSpec.help_txt:
+            summary = "N/A"
+            doc = summary + "\n"
+        else:
+            # Extract out the top line summary from the body and
+            # clean-up the unwanted whitespace
+            summary,doc = doc.split("\n", 1)
+            #doc = indent_re.sub('', doc)
+            while (doc[-2:] == '\n\n' or doc[-1:] == ' '):
+                doc = doc[:-1]
+
+        # Note: The leading : here are HACKs to get reStructuredText
+        # 'field' formatting - we know that the prefix ends in a ':'.
+        out.append(":%s\n\t%s" % (i.prefix, summary))
+        details.append(":%s\n%s" % (i.prefix, doc))
+
+    return '\n'.join(out + details)
+
+
+def _help_on_transport(name):
+    from bzrlib.transport import (
+        transport_list_registry,
+    )
+    import textwrap
+
+    def add_string(proto, help, maxl, prefix_width=20):
+       help_lines = textwrap.wrap(help, maxl - prefix_width,
+            break_long_words=False)
+       line_with_indent = '\n' + ' ' * prefix_width
+       help_text = line_with_indent.join(help_lines)
+       return "%-20s%s\n" % (proto, help_text)
+
+    def sort_func(a,b):
+        a1 = a[:a.rfind("://")]
+        b1 = b[:b.rfind("://")]
+        if a1>b1:
+            return +1
+        elif a1<b1:
+            return -1
+        else:
+            return 0
+
+    protl = []
+    decl = []
+    protos = transport_list_registry.keys( )
+    protos.sort(sort_func)
+    for proto in protos:
+        shorthelp = transport_list_registry.get_help(proto)
+        if not shorthelp:
+            continue
+        if proto.endswith("://"):
+            protl.append(add_string(proto, shorthelp, 79))
+        else:
+            decl.append(add_string(proto, shorthelp, 79))
+
+
+    out = "URL Identifiers\n\n" + \
+            "Supported URL prefixes::\n\n  " + \
+            '  '.join(protl)
+
+    if len(decl):
+        out += "\nSupported modifiers::\n\n  " + \
+            '  '.join(decl)
+
+    out += """\
+\nBazaar supports all of the standard parts within the URL::
+
+  <protocol>://[user[:password]@]host[:port]/[path]
+
+allowing URLs such as::
+
+  http://bzruser:BadPass@bzr.example.com:8080/bzr/trunk
+
+For bzr+ssh:// and sftp:// URLs, Bazaar also supports paths that begin
+with '~' as meaning that the rest of the path should be interpreted
+relative to the remote user's home directory.  For example if the user
+``remote`` has a  home directory of ``/home/remote`` on the server
+shell.example.com, then::
+
+  bzr+ssh://remote@shell.example.com/~/myproject/trunk
+
+would refer to ``/home/remote/myproject/trunk``.
+
+Many commands that accept URLs also accept location aliases too.
+See :doc:`location-alias-help` and :doc:`url-special-chars-help`.
+"""
+
+    return out
+
+
+_basic_help = \
+"""Bazaar %s -- a free distributed version-control tool
+http://bazaar.canonical.com/
+
+Basic commands:
+  bzr init           makes this directory a versioned branch
+  bzr branch         make a copy of another branch
+
+  bzr add            make files or directories versioned
+  bzr ignore         ignore a file or pattern
+  bzr mv             move or rename a versioned file
+
+  bzr status         summarize changes in working copy
+  bzr diff           show detailed diffs
+
+  bzr merge          pull in changes from another branch
+  bzr commit         save some or all changes
+  bzr send           send changes via email
+
+  bzr log            show history of changes
+  bzr check          validate storage
+
+  bzr help init      more help on e.g. init command
+  bzr help commands  list all commands
+  bzr help topics    list all help topics
+""" % bzrlib.__version__
+
+
+_global_options = \
+"""Global Options
+
+These options may be used with any command, and may appear in front of any
+command.  (e.g. ``bzr --profile help``).
+
+--version      Print the version number. Must be supplied before the command.
+--no-aliases   Do not process command aliases when running this command.
+--builtin      Use the built-in version of a command, not the plugin version.
+               This does not suppress other plugin effects.
+--no-plugins   Do not process any plugins.
+--no-l10n      Do not translate messages.
+--concurrency  Number of processes that can be run concurrently (selftest).
+
+--profile      Profile execution using the hotshot profiler.
+--lsprof       Profile execution using the lsprof profiler.
+--lsprof-file  Profile execution using the lsprof profiler, and write the
+               results to a specified file.  If the filename ends with ".txt",
+               text format will be used.  If the filename either starts with
+               "callgrind.out" or end with ".callgrind", the output will be
+               formatted for use with KCacheGrind. Otherwise, the output
+               will be a pickle.
+--coverage     Generate line coverage report in the specified directory.
+
+-Oname=value   Override the ``name`` config option setting it to ``value`` for
+               the duration of the command.  This can be used multiple times if
+               several options need to be overridden.
+
+See http://doc.bazaar.canonical.com/developers/profiling.html for more
+information on profiling.
+
+A number of debug flags are also available to assist troubleshooting and
+development.  See :doc:`debug-flags-help`.
+"""
+
+_standard_options = \
+"""Standard Options
+
+Standard options are legal for all commands.
+
+--help, -h     Show help message.
+--verbose, -v  Display more information.
+--quiet, -q    Only display errors and warnings.
+
+Unlike global options, standard options can be used in aliases.
+"""
+
+
+_checkouts = \
+"""Checkouts
+
+Checkouts are source trees that are connected to a branch, so that when
+you commit in the source tree, the commit goes into that branch.  They
+allow you to use a simpler, more centralized workflow, ignoring some of
+Bazaar's decentralized features until you want them. Using checkouts
+with shared repositories is very similar to working with SVN or CVS, but
+doesn't have the same restrictions.  And using checkouts still allows
+others working on the project to use whatever workflow they like.
+
+A checkout is created with the bzr checkout command (see "help checkout").
+You pass it a reference to another branch, and it will create a local copy
+for you that still contains a reference to the branch you created the
+checkout from (the master branch). Then if you make any commits they will be
+made on the other branch first. This creates an instant mirror of your work, or
+facilitates lockstep development, where each developer is working together,
+continuously integrating the changes of others.
+
+However the checkout is still a first class branch in Bazaar terms, so that
+you have the full history locally.  As you have a first class branch you can
+also commit locally if you want, for instance due to the temporary loss af a
+network connection. Use the --local option to commit to do this. All the local
+commits will then be made on the master branch the next time you do a non-local
+commit.
+
+If you are using a checkout from a shared branch you will periodically want to
+pull in all the changes made by others. This is done using the "update"
+command. The changes need to be applied before any non-local commit, but
+Bazaar will tell you if there are any changes and suggest that you use this
+command when needed.
+
+It is also possible to create a "lightweight" checkout by passing the
+--lightweight flag to checkout. A lightweight checkout is even closer to an
+SVN checkout in that it is not a first class branch, it mainly consists of the
+working tree. This means that any history operations must query the master
+branch, which could be slow if a network connection is involved. Also, as you
+don't have a local branch, then you cannot commit locally.
+
+Lightweight checkouts work best when you have fast reliable access to the
+master branch. This means that if the master branch is on the same disk or LAN
+a lightweight checkout will be faster than a heavyweight one for any commands
+that modify the revision history (as only one copy of the branch needs to
+be updated). Heavyweight checkouts will generally be faster for any command
+that uses the history but does not change it, but if the master branch is on
+the same disk then there won't be a noticeable difference.
+
+Another possible use for a checkout is to use it with a treeless repository
+containing your branches, where you maintain only one working tree by
+switching the master branch that the checkout points to when you want to
+work on a different branch.
+
+Obviously to commit on a checkout you need to be able to write to the master
+branch. This means that the master branch must be accessible over a writeable
+protocol , such as sftp://, and that you have write permissions at the other
+end. Checkouts also work on the local file system, so that all that matters is
+file permissions.
+
+You can change the master of a checkout by using the "switch" command (see
+"help switch").  This will change the location that the commits are sent to.
+The "bind" command can also be used to turn a normal branch into a heavy
+checkout. If you would like to convert your heavy checkout into a normal
+branch so that every commit is local, you can use the "unbind" command. To see
+whether or not a branch is bound or not you can use the "info" command. If the
+branch is bound it will tell you the location of the bound branch.
+
+Related commands::
+
+  checkout    Create a checkout. Pass --lightweight to get a lightweight
+              checkout
+  update      Pull any changes in the master branch in to your checkout
+  commit      Make a commit that is sent to the master branch. If you have
+              a heavy checkout then the --local option will commit to the
+              checkout without sending the commit to the master
+  switch      Change the master branch that the commits in the checkout will
+              be sent to
+  bind        Turn a standalone branch into a heavy checkout so that any
+              commits will be sent to the master branch
+  unbind      Turn a heavy checkout into a standalone branch so that any
+              commits are only made locally
+  info        Displays whether a branch is bound or unbound. If the branch is
+              bound, then it will also display the location of the bound branch
+"""
+
+_repositories = \
+"""Repositories
+
+Repositories in Bazaar are where committed information is stored. There is
+a repository associated with every branch.
+
+Repositories are a form of database. Bzr will usually maintain this for
+good performance automatically, but in some situations (e.g. when doing
+very many commits in a short time period) you may want to ask bzr to
+optimise the database indices. This can be done by the 'bzr pack' command.
+
+By default just running 'bzr init' will create a repository within the new
+branch but it is possible to create a shared repository which allows multiple
+branches to share their information in the same location. When a new branch is
+created it will first look to see if there is a containing shared repository it
+can use.
+
+When two branches of the same project share a repository, there is
+generally a large space saving. For some operations (e.g. branching
+within the repository) this translates in to a large time saving.
+
+To create a shared repository use the init-repository command (or the alias
+init-repo). This command takes the location of the repository to create. This
+means that 'bzr init-repository repo' will create a directory named 'repo',
+which contains a shared repository. Any new branches that are created in this
+directory will then use it for storage.
+
+It is a good idea to create a repository whenever you might create more
+than one branch of a project. This is true for both working areas where you
+are doing the development, and any server areas that you use for hosting
+projects. In the latter case, it is common to want branches without working
+trees. Since the files in the branch will not be edited directly there is no
+need to use up disk space for a working tree. To create a repository in which
+the branches will not have working trees pass the '--no-trees' option to
+'init-repository'.
+
+Related commands::
+
+  init-repository   Create a shared repository. Use --no-trees to create one
+                    in which new branches won't get a working tree.
+"""
+
+
+_working_trees = \
+"""Working Trees
+
+A working tree is the contents of a branch placed on disk so that you can
+see the files and edit them. The working tree is where you make changes to a
+branch, and when you commit the current state of the working tree is the
+snapshot that is recorded in the commit.
+
+When you push a branch to a remote system, a working tree will not be
+created. If one is already present the files will not be updated. The
+branch information will be updated and the working tree will be marked
+as out-of-date. Updating a working tree remotely is difficult, as there
+may be uncommitted changes or the update may cause content conflicts that are
+difficult to deal with remotely.
+
+If you have a branch with no working tree you can use the 'checkout' command
+to create a working tree. If you run 'bzr checkout .' from the branch it will
+create the working tree. If the branch is updated remotely, you can update the
+working tree by running 'bzr update' in that directory.
+
+If you have a branch with a working tree that you do not want the 'remove-tree'
+command will remove the tree if it is safe. This can be done to avoid the
+warning about the remote working tree not being updated when pushing to the
+branch. It can also be useful when working with a '--no-trees' repository
+(see 'bzr help repositories').
+
+If you want to have a working tree on a remote machine that you push to you
+can either run 'bzr update' in the remote branch after each push, or use some
+other method to update the tree during the push. There is an 'rspush' plugin
+that will update the working tree using rsync as well as doing a push. There
+is also a 'push-and-update' plugin that automates running 'bzr update' via SSH
+after each push.
+
+Useful commands::
+
+  checkout     Create a working tree when a branch does not have one.
+  remove-tree  Removes the working tree from a branch when it is safe to do so.
+  update       When a working tree is out of sync with its associated branch
+               this will update the tree to match the branch.
+"""
+
+
+_branches = \
+"""Branches
+
+A branch consists of the state of a project, including all of its
+history. All branches have a repository associated (which is where the
+branch history is stored), but multiple branches may share the same
+repository (a shared repository). Branches can be copied and merged.
+
+In addition, one branch may be bound to another one.  Binding to another
+branch indicates that commits which happen in this branch must also 
+happen in the other branch.  Bazaar ensures consistency by not allowing 
+commits when the two branches are out of date.  In order for a commit 
+to succeed, it may be necessary to update the current branch using 
+``bzr update``.
+
+Related commands::
+
+  init    Change a directory into a versioned branch.
+  branch  Create a new branch that is a copy of an existing branch.
+  merge   Perform a three-way merge.
+  bind    Bind a branch to another one.
+"""
+
+
+_standalone_trees = \
+"""Standalone Trees
+
+A standalone tree is a working tree with an associated repository. It
+is an independently usable branch, with no dependencies on any other.
+Creating a standalone tree (via bzr init) is the quickest way to put
+an existing project under version control.
+
+Related Commands::
+
+  init    Make a directory into a versioned branch.
+"""
+
+
+_status_flags = \
+"""Status Flags
+
+Status flags are used to summarise changes to the working tree in a concise
+manner.  They are in the form::
+
+   xxx   <filename>
+
+where the columns' meanings are as follows.
+
+Column 1 - versioning/renames::
+
+  + File versioned
+  - File unversioned
+  R File renamed
+  ? File unknown
+  X File nonexistent (and unknown to bzr)
+  C File has conflicts
+  P Entry for a pending merge (not a file)
+
+Column 2 - contents::
+
+  N File created
+  D File deleted
+  K File kind changed
+  M File modified
+
+Column 3 - execute::
+
+  * The execute bit was changed
+"""
+
+
+known_env_variables = [
+    ("BZRPATH", "Path where bzr is to look for shell plugin external commands."),
+    ("BZR_EMAIL", "E-Mail address of the user. Overrides EMAIL."),
+    ("EMAIL", "E-Mail address of the user."),
+    ("BZR_EDITOR", "Editor for editing commit messages. Overrides EDITOR."),
+    ("EDITOR", "Editor for editing commit messages."),
+    ("BZR_PLUGIN_PATH", "Paths where bzr should look for plugins."),
+    ("BZR_DISABLE_PLUGINS", "Plugins that bzr should not load."),
+    ("BZR_PLUGINS_AT", "Plugins to load from a directory not in BZR_PLUGIN_PATH."),
+    ("BZR_HOME", "Directory holding .bazaar config dir. Overrides HOME."),
+    ("BZR_HOME (Win32)", "Directory holding bazaar config dir. Overrides APPDATA and HOME."),
+    ("BZR_REMOTE_PATH", "Full name of remote 'bzr' command (for bzr+ssh:// URLs)."),
+    ("BZR_SSH", "Path to SSH client, or one of paramiko, openssh, sshcorp, plink or lsh."),
+    ("BZR_LOG", "Location of .bzr.log (use '/dev/null' to suppress log)."),
+    ("BZR_LOG (Win32)", "Location of .bzr.log (use 'NUL' to suppress log)."),
+    ("BZR_COLUMNS", "Override implicit terminal width."),
+    ("BZR_CONCURRENCY", "Number of processes that can be run concurrently (selftest)"),
+    ("BZR_PROGRESS_BAR", "Override the progress display. Values are 'none' or 'text'."),
+    ("BZR_PDB", "Control whether to launch a debugger on error."),
+    ("BZR_SIGQUIT_PDB", "Control whether SIGQUIT behaves normally or invokes a breakin debugger."),
+    ("BZR_TEXTUI_INPUT", "Force console input mode for prompts to line-based (instead of char-based)."),
+    ]
+
+def _env_variables(topic):
+    import textwrap
+    ret = ["Environment Variables\n\n"]
+    max_key_len = max([len(k[0]) for k in known_env_variables])
+    desc_len = (80 - max_key_len - 2)
+    ret.append("=" * max_key_len + " " + "=" * desc_len + "\n")
+    for k, desc in known_env_variables:
+        ret.append(k + (max_key_len + 1 - len(k)) * " ")
+        ret.append("\n".join(textwrap.wrap(
+            desc, width=desc_len, subsequent_indent=" " * (max_key_len + 1))))
+        ret.append("\n")
+    ret += "=" * max_key_len + " " + "=" * desc_len + "\n"
+    return "".join(ret)
+
+_files = \
+r"""Files
+
+:On Unix:   ~/.bazaar/bazaar.conf
+:On Windows: C:\\Documents and Settings\\username\\Application Data\\bazaar\\2.0\\bazaar.conf
+
+Contains the user's default configuration. The section ``[DEFAULT]`` is
+used to define general configuration that will be applied everywhere.
+The section ``[ALIASES]`` can be used to create command aliases for
+commonly used options.
+
+A typical config file might look something like::
+
+  [DEFAULT]
+  email=John Doe <jdoe@isp.com>
+
+  [ALIASES]
+  commit = commit --strict
+  log10 = log --short -r -10..-1
+"""
+
+_criss_cross = \
+"""Criss-Cross
+
+A criss-cross in the branch history can cause the default merge technique
+to emit more conflicts than would normally be expected.
+
+In complex merge cases, ``bzr merge --lca`` or ``bzr merge --weave`` may give
+better results.  You may wish to ``bzr revert`` the working tree and merge
+again.  Alternatively, use ``bzr remerge`` on particular conflicted files.
+
+Criss-crosses occur in a branch's history if two branches merge the same thing
+and then merge one another, or if two branches merge one another at the same
+time.  They can be avoided by having each branch only merge from or into a
+designated central branch (a "star topology").
+
+Criss-crosses cause problems because of the way merge works.  Bazaar's default
+merge is a three-way merger; in order to merge OTHER into THIS, it must
+find a basis for comparison, BASE.  Using BASE, it can determine whether
+differences between THIS and OTHER are due to one side adding lines, or
+from another side removing lines.
+
+Criss-crosses mean there is no good choice for a base.  Selecting the recent
+merge points could cause one side's changes to be silently discarded.
+Selecting older merge points (which Bazaar does) mean that extra conflicts
+are emitted.
+
+The ``weave`` merge type is not affected by this problem because it uses
+line-origin detection instead of a basis revision to determine the cause of
+differences.
+"""
+
+_branches_out_of_sync = """Branches Out of Sync
+
+When reconfiguring a checkout, tree or branch into a lightweight checkout,
+a local branch must be destroyed.  (For checkouts, this is the local branch
+that serves primarily as a cache.)  If the branch-to-be-destroyed does not
+have the same last revision as the new reference branch for the lightweight
+checkout, data could be lost, so Bazaar refuses.
+
+How you deal with this depends on *why* the branches are out of sync.
+
+If you have a checkout and have done local commits, you can get back in sync
+by running "bzr update" (and possibly "bzr commit").
+
+If you have a branch and the remote branch is out-of-date, you can push
+the local changes using "bzr push".  If the local branch is out of date, you
+can do "bzr pull".  If both branches have had changes, you can merge, commit
+and then push your changes.  If you decide that some of the changes aren't
+useful, you can "push --overwrite" or "pull --overwrite" instead.
+"""
+
+
+_storage_formats = \
+"""Storage Formats
+
+To ensure that older clients do not access data incorrectly,
+Bazaar's policy is to introduce a new storage format whenever
+new features requiring new metadata are added. New storage
+formats may also be introduced to improve performance and
+scalability.
+
+The newest format, 2a, is highly recommended. If your
+project is not using 2a, then you should suggest to the
+project owner to upgrade.
+
+
+.. note::
+
+   Some of the older formats have two variants:
+   a plain one and a rich-root one. The latter include an additional
+   field about the root of the tree. There is no performance cost
+   for using a rich-root format but you cannot easily merge changes
+   from a rich-root format into a plain format. As a consequence,
+   moving a project to a rich-root format takes some co-ordination
+   in that all contributors need to upgrade their repositories
+   around the same time. 2a and all future formats will be
+   implicitly rich-root.
+
+See :doc:`current-formats-help` for the complete list of
+currently supported formats. See :doc:`other-formats-help` for
+descriptions of any available experimental and deprecated formats.
+"""
+
+
+# Register help topics
+topic_registry.register("revisionspec", _help_on_revisionspec,
+                        "Explain how to use --revision")
+topic_registry.register('basic', _basic_help, "Basic commands", SECT_HIDDEN)
+topic_registry.register('topics', _help_on_topics, "Topics list", SECT_HIDDEN)
+def get_current_formats_topic(topic):
+    from bzrlib import controldir
+    return "Current Storage Formats\n\n" + \
+        controldir.format_registry.help_topic(topic)
+def get_other_formats_topic(topic):
+    from bzrlib import controldir
+    return "Other Storage Formats\n\n" + \
+        controldir.format_registry.help_topic(topic)
+topic_registry.register('current-formats', get_current_formats_topic,
+    'Current storage formats')
+topic_registry.register('other-formats', get_other_formats_topic,
+    'Experimental and deprecated storage formats')
+topic_registry.register('standard-options', _standard_options,
+                        'Options that can be used with any command')
+topic_registry.register('global-options', _global_options,
+                    'Options that control how Bazaar runs')
+topic_registry.register('urlspec', _help_on_transport,
+                        "Supported transport protocols")
+topic_registry.register('status-flags', _status_flags,
+                        "Help on status flags")
+def get_bugs_topic(topic):
+    from bzrlib import bugtracker
+    return ("Bug Tracker Settings\n\n" +
+        bugtracker.tracker_registry.help_topic(topic))
+topic_registry.register('bugs', get_bugs_topic, 'Bug tracker settings')
+topic_registry.register('env-variables', _env_variables,
+                        'Environment variable names and values')
+topic_registry.register('files', _files,
+                        'Information on configuration and log files')
+topic_registry.register_lazy('hooks', 'bzrlib.hooks', 'hooks_help_text',
+                        'Points at which custom processing can be added')
+topic_registry.register_lazy('location-alias', 'bzrlib.directory_service',
+                        'AliasDirectory.help_text',
+                        'Aliases for remembered locations')
+
+# Load some of the help topics from files. Note that topics which reproduce API
+# details will tend to skew (quickly usually!) so please seek other solutions
+# for such things.
+topic_registry.register('authentication', _load_from_file,
+                        'Information on configuring authentication')
+topic_registry.register('configuration', _load_from_file,
+                        'Details on the configuration settings available')
+topic_registry.register('conflict-types', _load_from_file,
+                        'Types of conflicts and what to do about them')
+topic_registry.register('debug-flags', _load_from_file,
+                        'Options to show or record debug information')
+topic_registry.register('log-formats', _load_from_file,
+                        'Details on the logging formats available')
+topic_registry.register('url-special-chars', _load_from_file,
+                        'Special character handling in URLs')
+
+
+# Register concept topics.
+# Note that we might choose to remove these from the online help in the
+# future or implement them via loading content from files. In the meantime,
+# please keep them concise.
+topic_registry.register('branches', _branches,
+                        'Information on what a branch is', SECT_CONCEPT)
+topic_registry.register('checkouts', _checkouts,
+                        'Information on what a checkout is', SECT_CONCEPT)
+topic_registry.register('content-filters', _load_from_file,
+                        'Conversion of content into/from working trees',
+                        SECT_CONCEPT)
+topic_registry.register('diverged-branches', _load_from_file,
+                        'How to fix diverged branches',
+                        SECT_CONCEPT)
+topic_registry.register('eol', _load_from_file,
+                        'Information on end-of-line handling',
+                        SECT_CONCEPT)
+topic_registry.register('formats', _storage_formats,
+                        'Information on choosing a storage format',
+                        SECT_CONCEPT)
+topic_registry.register('patterns', _load_from_file,
+                        'Information on the pattern syntax',
+                        SECT_CONCEPT)
+topic_registry.register('repositories', _repositories,
+                        'Basic information on shared repositories.',
+                        SECT_CONCEPT)
+topic_registry.register('rules', _load_from_file,
+                        'Information on defining rule-based preferences',
+                        SECT_CONCEPT)
+topic_registry.register('standalone-trees', _standalone_trees,
+                        'Information on what a standalone tree is',
+                        SECT_CONCEPT)
+topic_registry.register('working-trees', _working_trees,
+                        'Information on working trees', SECT_CONCEPT)
+topic_registry.register('criss-cross', _criss_cross,
+                        'Information on criss-cross merging', SECT_CONCEPT)
+topic_registry.register('sync-for-reconfigure', _branches_out_of_sync,
+                        'Steps to resolve "out-of-sync" when reconfiguring',
+                        SECT_CONCEPT)
+
+
+class HelpTopicIndex(object):
+    """A index for bzr help that returns topics."""
+
+    def __init__(self):
+        self.prefix = ''
+
+    def get_topics(self, topic):
+        """Search for topic in the HelpTopicRegistry.
+
+        :param topic: A topic to search for. None is treated as 'basic'.
+        :return: A list which is either empty or contains a single
+            RegisteredTopic entry.
+        """
+        if topic is None:
+            topic = 'basic'
+        if topic in topic_registry:
+            return [RegisteredTopic(topic)]
+        else:
+            return []
+
+
+def _format_see_also(see_also):
+    result = ''
+    if see_also:
+        result += '\n:See also: '
+        result += ', '.join(sorted(set(see_also)))
+        result += '\n'
+    return result
+
+
+class RegisteredTopic(object):
+    """A help topic which has been registered in the HelpTopicRegistry.
+
+    These topics consist of nothing more than the name of the topic - all
+    data is retrieved on demand from the registry.
+    """
+
+    def __init__(self, topic):
+        """Constructor.
+
+        :param topic: The name of the topic that this represents.
+        """
+        self.topic = topic
+
+    def get_help_text(self, additional_see_also=None, plain=True):
+        """Return a string with the help for this topic.
+
+        :param additional_see_also: Additional help topics to be
+            cross-referenced.
+        :param plain: if False, raw help (reStructuredText) is
+            returned instead of plain text.
+        """
+        result = topic_registry.get_detail(self.topic)
+        result += _format_see_also(additional_see_also)
+        if plain:
+            result = help_as_plain_text(result)
+        i18n.install()
+        result = i18n.gettext_per_paragraph(result)
+        return result
+
+    def get_help_topic(self):
+        """Return the help topic this can be found under."""
+        return self.topic
+
+
+def help_as_plain_text(text):
+    """Minimal converter of reStructuredText to plain text."""
+    import re
+    # Remove the standalone code block marker
+    text = re.sub(r"(?m)^\s*::\n\s*$", "", text)
+    lines = text.splitlines()
+    result = []
+    for line in lines:
+        if line.startswith(':'):
+            line = line[1:]
+        elif line.endswith('::'):
+            line = line[:-1]
+        # Map :doc:`xxx-help` to ``bzr help xxx``
+        line = re.sub(":doc:`(.+?)-help`", r'``bzr help \1``', line)
+        result.append(line)
+    return "\n".join(result) + "\n"
+
+
+class ConfigOptionHelpIndex(object):
+    """A help index that returns help topics for config options."""
+
+    def __init__(self):
+        self.prefix = 'configuration/'
+
+    def get_topics(self, topic):
+        """Search for topic in the registered config options.
+
+        :param topic: A topic to search for.
+        :return: A list which is either empty or contains a single
+            config.Option entry.
+        """
+        if topic is None:
+            return []
+        elif topic.startswith(self.prefix):
+            topic = topic[len(self.prefix):]
+        if topic in config.option_registry:
+            return [config.option_registry.get(topic)]
+        else:
+            return []
+
+
diff --git a/bzrlib/help_topics/en/authentication.txt b/bzrlib/help_topics/en/authentication.txt
new file mode 100644
index 0000000..805093c
--- /dev/null
+++ b/bzrlib/help_topics/en/authentication.txt
@@ -0,0 +1,226 @@
+Authentication Settings
+=======================
+
+
+Intent
+------
+
+Many different authentication policies can be described in the
+``authentication.conf`` file but a particular user should need only a few
+definitions to cover his needs without having to specify a user and a password
+for every branch he uses.
+
+The definitions found in this file are used to find the credentials to use for
+a given url. The same credentials can generally be used for as many branches as
+possible by grouping their declaration around the remote servers that need
+them. It's even possible to declare credentials that will be used by different
+servers.
+
+The intent is to make this file as small as possible to minimize maintenance.
+
+Once the relevant credentials are declared in this file you may use branch urls
+without embedding passwords (security hazard) or even users (enabling sharing
+of your urls with others).
+
+Instead of using::
+
+  bzr branch ftp://joe:secret@host.com/path/to/my/branch
+
+you simply use::
+
+  bzr branch ftp://host.com/path/to/my/branch
+
+provided you have created the following ``authentication.conf`` file::
+
+  [myprojects]
+  scheme=ftp
+  host=host.com
+  user=joe
+  password=secret
+  
+
+Authentication definitions
+--------------------------
+
+There are two kinds of authentication used by the various schemes supported by
+bzr:
+
+1. user and password
+
+``FTP`` needs a (``user``, ``password``) to authenticate against a ``host``
+``SFTP`` can use either a password or a host key to authenticate. However,
+ssh agents are a better, more secure solution. So we have chosen to not provide
+our own less secure method.
+
+2. user, realm and password
+
+``HTTP`` and ``HTTPS`` needs a (``user, realm, password``) to authenticate
+against a host. But, by using ``.htaccess`` files, for example, it is possible
+to define several (``user, realm, password``) for a given ``host``. So what is
+really needed is (``user``, ``password``, ``host``, ``path``). The ``realm`` is
+not taken into account in the definitions, but will displayed if bzr prompts
+you for a password.
+
+``HTTP proxy`` can be handled as ``HTTP`` (or ``HTTPS``) by explicitly
+specifying the appropriate port.
+
+To take all schemes into account, the password will be deduced from a set of
+authentication definitions (``scheme``, ``host``, ``port``, ``path``, ``user``,
+``password``).
+
+  * ``scheme``: can be empty (meaning the rest of the definition can be used
+    for any scheme), ``SFTP`` and ``bzr+ssh`` should not be used here, ``ssh``
+    should be used instead since this is the real scheme regarding
+    authentication,
+
+  * ``host``: can be empty (to act as a default for any host),
+
+  * ``port`` can be empty (useful when an host provides several servers for the
+    same scheme), only numerical values are allowed, this should be used only
+    when the server uses a port different than the scheme standard port,
+
+  * ``path``: can be empty (FTP or SFTP will never user it),
+
+  * ``user``: can be empty (``bzr`` will defaults to python's
+    ``getpass.get_user()``),
+
+  * ``password``: can be empty if you prefer to always be prompted for your
+    password.
+
+Multiple definitions can be provided and, for a given URL, bzr will select a
+(``user`` [, ``password``]) based on the following rules :
+
+ 1. the first match wins,
+
+ 2. empty fields match everything,
+
+ 3. ``scheme`` matches even if decorators are used in the requested URL,
+
+ 4. ``host`` matches exactly or act as a domain if it starts with '.'
+    (``project.bzr.sf.net`` will match ``.bzr.sf.net`` but ``projectbzr.sf.net``
+    will not match ``bzr.sf.net``).
+
+ 5. ``port`` matches if included in the requested URL (exact matches only)
+
+ 6. ``path`` matches if included in the requested URL (and by rule #2 above,
+    empty paths will match any provided path).
+
+
+
+File format
+-----------
+
+The general rules for :doc:`configuration files <configuration-help>`
+apply except for the variable policies.
+
+Each section describes an authentication definition.
+
+The section name is an arbitrary string, only the ``DEFAULT`` value is reserved
+and should appear as the *last* section.
+
+Each section should define:
+
+* ``user``: the login to be used,
+
+Each section could define:
+
+* ``host``: the remote server,
+
+* ``port``: the port the server is listening,
+
+* ``path``: the branch location,
+
+* ``password``: the password.
+
+
+Examples
+--------
+
+
+Personal projects hosted outside
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+All connections are done with the same ``user`` (the remote one for which the
+default bzr one is not appropriate) and the password is always prompted with
+some exceptions::
+
+        # Pet projects on hobby.net
+        [hobby]
+        host=r.hobby.net
+        user=jim
+        password=obvious1234
+        
+        # Home server
+        [home]
+        scheme=https
+        host=home.net
+        user=joe
+        password=1essobV10us
+        
+        [DEFAULT]
+        # Our local user is barbaz, on all remote sites we're known as foobar
+        user=foobar
+
+
+Source hosting provider
+~~~~~~~~~~~~~~~~~~~~~~~
+
+In the shp.net (fictitious) domain, each project has its own site::
+
+        [shpnet domain]
+        # we use sftp, but ssh is the scheme used for authentication
+        scheme=ssh
+        # The leading '.' ensures that 'shp.net' alone doesn't match
+        host=.shp.net
+        user=joe
+        # bzr don't support supplying a password for sftp,
+        # consider using an ssh agent if you don't want to supply
+        # a password interactively. (pageant, ssh-agent, etc)
+
+HTTPS, SFTP servers and their proxy
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+At company.com, the server hosting release and integration branches is behind a
+proxy, and the two branches use different authentication policies::
+
+        [reference code]
+        scheme=https
+        host=dev.company.com
+        path=/dev
+        user=user1
+        password=pass1
+
+        # development branches on dev server
+        [dev]
+        scheme=ssh # bzr+ssh and sftp are available here
+        host=dev.company.com
+        path=/dev/integration
+        user=user2
+        
+        # proxy
+        [proxy]
+        scheme=http
+        host=proxy.company.com
+        port=3128
+        user=proxyuser1
+        password=proxypass1
+
+
+Planned enhancements
+--------------------
+
+The following are not yet implemented but planned as parts of a work in
+progress:
+
+* add a  ``password_encoding`` field allowing:
+
+  - storing the passwords in various obfuscating encodings (base64 for one),
+
+  - delegate password storage to plugins (.netrc for example).
+
+* update the credentials when the user is prompted for user or password,
+
+* add a ``verify_certificates`` field for ``HTTPS``.
+
+The ``password_encoding`` and ``verify_certificates`` fields are recognized but
+ignored in the actual implementation.
diff --git a/bzrlib/help_topics/en/configuration.txt b/bzrlib/help_topics/en/configuration.txt
new file mode 100644
index 0000000..ab473bd
--- /dev/null
+++ b/bzrlib/help_topics/en/configuration.txt
@@ -0,0 +1,724 @@
+Configuration Settings
+=======================
+
+Environment settings
+---------------------
+
+While most configuration is handled by configuration files, some options
+which may be semi-permanent can also be controlled through the environment.
+
+BZR_EMAIL
+~~~~~~~~~
+
+Override the email id used by Bazaar.  Typical format::
+
+  "John Doe <jdoe@example.com>"
+
+See also the ``email`` configuration option.
+
+BZR_PROGRESS_BAR
+~~~~~~~~~~~~~~~~
+
+Override the progress display.  Possible values are "none" or "text".  If
+the value is "none" then no progress bar is displayed.  The value "text" draws
+the ordinary command line progress bar.
+
+BZR_SIGQUIT_PDB
+~~~~~~~~~~~~~~~
+
+Control whether SIGQUIT behaves normally or invokes a breakin debugger.
+
+* 0 = Standard SIGQUIT behavior (normally, exit with a core dump)
+* 1 = Invoke breakin debugger (default)
+
+BZR_HOME
+~~~~~~~~
+
+Override the home directory used by Bazaar.
+
+BZR_SSH
+~~~~~~~
+
+Select a different SSH implementation.
+
+BZR_PDB
+~~~~~~~
+
+Control whether to launch a debugger on error.
+
+* 0 = Standard behavior
+* 1 = Launch debugger
+
+BZR_REMOTE_PATH
+~~~~~~~~~~~~~~~
+
+Path to the Bazaar executable to use when using the bzr+ssh protocol.
+
+See also the ``bzr_remote_path`` configuration option.
+
+BZR_EDITOR
+~~~~~~~~~~
+
+Path to the editor Bazaar should use for commit messages, etc.
+
+BZR_LOG
+~~~~~~~
+
+Location of the Bazaar log file. You can check the current location by
+running ``bzr version``.
+
+The log file contains debug information that is useful for diagnosing or
+reporting problems with Bazaar.
+
+Setting this to ``NUL`` on Windows or ``/dev/null`` on other platforms
+will disable logging.
+
+
+BZR_PLUGIN_PATH
+~~~~~~~~~~~~~~~
+
+The path to the plugins directory that Bazaar should use.
+If not set, Bazaar will search for plugins in:
+
+* the user specific plugin directory (containing the ``user`` plugins),
+
+* the bzrlib directory (containing the ``core`` plugins),
+
+* the site specific plugin directory if applicable (containing
+  the ``site`` plugins).
+
+If ``BZR_PLUGIN_PATH`` is set in any fashion, it will change the
+the way the plugin are searched. 
+
+As for the ``PATH`` variables, if multiple directories are
+specified in ``BZR_PLUGIN_PATH`` they should be separated by the
+platform specific appropriate character (':' on Unix,
+';' on windows)
+
+By default if ``BZR_PLUGIN_PATH`` is set, it replaces searching
+in ``user``.  However it will continue to search in ``core`` and
+``site`` unless they are explicitly removed.
+
+If you need to change the order or remove one of these
+directories, you should use special values:
+
+* ``-user``, ``-core``, ``-site`` will remove the corresponding
+  path from the default values,
+
+* ``+user``, ``+core``, ``+site`` will add the corresponding path
+  before the remaining default values (and also remove it from
+  the default values).
+
+Note that the special values 'user', 'core' and 'site' should be
+used literally, they will be substituted by the corresponding,
+platform specific, values.
+
+The examples below use ':' as the separator, windows users
+should use ';'.
+
+Overriding the default user plugin directory::
+
+  BZR_PLUGIN_PATH='/path/to/my/other/plugins'
+
+Disabling the site directory while retaining the user directory::
+
+  BZR_PLUGIN_PATH='-site:+user'
+
+Disabling all plugins (better achieved with --no-plugins)::
+
+  BZR_PLUGIN_PATH='-user:-core:-site'
+
+Overriding the default site plugin directory::
+
+  BZR_PLUGIN_PATH='/path/to/my/site/plugins:-site':+user
+
+BZR_DISABLE_PLUGINS
+~~~~~~~~~~~~~~~~~~~
+
+Under special circumstances (mostly when trying to diagnose a
+bug), it's better to disable a plugin (or several) rather than
+uninstalling them completely. Such plugins can be specified in
+the ``BZR_DISABLE_PLUGINS`` environment variable.
+
+In that case, ``bzr`` will stop loading the specified plugins and
+will raise an import error if they are explicitly imported (by
+another plugin that depends on them for example).
+
+Disabling ``myplugin`` and ``yourplugin`` is achieved by::
+
+  BZR_DISABLE_PLUGINS='myplugin:yourplugin'
+
+BZR_PLUGINS_AT
+~~~~~~~~~~~~~~
+
+When adding a new feature or working on a bug in a plugin,
+developers often need to use a specific version of a given
+plugin. Since python requires that the directory containing the
+code is named like the plugin itself this make it impossible to
+use arbitrary directory names (using a two-level directory scheme
+is inconvenient). ``BZR_PLUGINS_AT`` allows such directories even
+if they don't appear in ``BZR_PLUGIN_PATH`` .
+
+Plugins specified in this environment variable takes precedence
+over the ones in ``BZR_PLUGIN_PATH``.
+
+The variable specified a list of ``plugin_name@plugin path``,
+``plugin_name`` being the name of the plugin as it appears in
+python module paths, ``plugin_path`` being the path to the
+directory containing the plugin code itself
+(i.e. ``plugins/myplugin`` not ``plugins``).  Use ':' as the list
+separator, use ';' on windows.
+
+Example:
+~~~~~~~~
+
+Using a specific version of ``myplugin``:
+``BZR_PLUGINS_AT='myplugin@/home/me/bugfixes/123456-myplugin``
+
+BZRPATH
+~~~~~~~
+
+The path where Bazaar should look for shell plugin external commands.
+
+
+http_proxy, https_proxy
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Specifies the network proxy for outgoing connections, for example::
+
+  http_proxy=http://proxy.example.com:3128/ 
+  https_proxy=http://proxy.example.com:3128/
+
+
+Configuration files
+-------------------
+
+Location
+~~~~~~~~
+
+Configuration files are located in ``$HOME/.bazaar`` on Unix and
+``C:\Documents and Settings\<username>\Application Data\Bazaar\2.0`` on
+Windows. (You can check the location for your system by using
+``bzr version``.)
+
+There are three primary configuration files in this location:
+
+* ``bazaar.conf`` describes default configuration options,
+
+* ``locations.conf`` describes configuration information for
+  specific branch locations,
+
+* ``authentication.conf`` describes credential information for
+  remote servers.
+
+Each branch can also contain a configuration file that sets values specific
+to that branch. This file is found at ``.bzr/branch/branch.conf`` within the
+branch. This file is visible to all users of a branch, if you wish to override
+one of the values for a branch with a setting that is specific to you then you
+can do so in ``locations.conf``.
+
+General format
+~~~~~~~~~~~~~~
+
+An ini file has three types of contructs: section headers, section
+options and comments.
+
+Comments
+^^^^^^^^
+
+A comment is any line that starts with a "#" (sometimes called a "hash
+mark", "pound sign" or "number sign"). Comment lines are ignored by
+Bazaar when parsing ini files.
+
+Section headers
+^^^^^^^^^^^^^^^
+
+A section header is a word enclosed in brackets that starts at the begining
+of a line.  A typical section header looks like this::
+
+    [DEFAULT]
+
+The only valid section headers for bazaar.conf currently are [DEFAULT] and
+[ALIASES].  Section headers are case sensitive. The default section provides for
+setting options which can be overridden with the branch config file.
+
+For ``locations.conf``, the options from the section with the
+longest matching section header are used to the exclusion of other
+potentially valid section headers. A section header uses the path for
+the branch as the section header. Some examples include::
+
+    [http://mybranches.isp.com/~jdoe/branchdir]
+    [/home/jdoe/branches/]
+
+
+Section options
+^^^^^^^^^^^^^^^
+
+A section option resides within a section. A section option contains an
+option name, an equals sign and a value.  For example::
+
+    email            = John Doe <jdoe@isp.com>
+    gpg_signing_key  = Amy Pond <amy@example.com>
+
+A option can reference other options by enclosing them in curly brackets::
+
+    my_branch_name = feature_x
+    my_server      = bzr+ssh://example.com
+    push_location   = {my_server}/project/{my_branch_name}
+
+Option policies
+^^^^^^^^^^^^^^^
+
+Options defined in a section affect the named directory or URL plus
+any locations they contain.  Policies can be used to change how an
+option value is interpreted for contained locations.  Currently
+there are three policies available:
+
+ none:
+   the value is interpreted the same for contained locations.  This is
+   the default behaviour.
+ norecurse:
+   the value is only used for the exact location specified by the
+   section name.
+ appendpath:
+   for contained locations, any additional path components are
+   appended to the value.
+
+Policies are specified by keys with names of the form "<option_name>:policy".
+For example, to define the push location for a tree of branches, the
+following could be used::
+
+  [/top/location]
+  push_location = sftp://example.com/location
+  push_location:policy = appendpath
+
+With this configuration, the push location for ``/top/location/branch1``
+would be ``sftp://example.com/location/branch1``.
+
+Section local options
+^^^^^^^^^^^^^^^^^^^^^
+
+Some options are defined automatically inside a given section and can be
+refered to in this section only. 
+
+For example, the ``appendpath`` policy can be used like this::
+
+  [/home/vila/src/bzr/bugs]
+  mypush = lp:~vila/bzr
+  mypush:policy=appendpath
+
+Using ``relpath`` to achieve the same result is done like this::
+
+  [/home/vila/src/bzr/bugs]
+  mypush = lp:~vila/bzr/{relpath}
+
+In both cases, when used in a directory like
+``/home/vila/src/bzr/bugs/832013-expand-in-stack`` we'll get::
+
+   $ bzr config mypush
+   lp:~vila/bzr/832013-expand-in-stack
+
+Another such option is ``basename`` which can be used like this::
+
+  [/home/vila/src/bzr]
+  mypush = lp:~vila/bzr/{basename}
+
+When used in a directory like
+``/home/vila/src/bzr/bugs/832013-expand-in-stack`` we'll get::
+
+   $ bzr config mypush
+   lp:~vila/bzr/832013-expand-in-stack
+
+Note that ``basename`` here refers to the base name of ``relpath`` which
+itself is defined as the relative path between the section name and the
+location it matches.
+
+Another such option is ``branchname``, which refers to the name of a colocated
+branch.  For non-colocated branches, it behaves like basename.  It can be used
+like this::
+
+  [/home/vila/src/bzr/bugs]
+  mypush = lp:~vila/bzr/{branchname}
+
+When used with a colocated branch named ``832013-expand-in-stack``, we'll get::
+
+  bzr config mypush
+  lp:~vila/bzr/832013-expand-in-stack
+
+When an option is local to a Section, it cannot be referred to from option
+values in any other section from the same ``Store`` nor from any other
+``Store``.
+
+
+The main configuration file, bazaar.conf
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+``bazaar.conf`` allows two sections: ``[DEFAULT]`` and ``[ALIASES]``.
+The default section contains the default
+configuration options for all branches. The default section can be
+overriden by providing a branch-specific section in ``locations.conf``.
+
+A typical ``bazaar.conf`` section often looks like the following::
+
+    [DEFAULT]
+    email             = John Doe <jdoe@isp.com>
+    editor            = /usr/bin/vim
+    create_signatures = when-required
+
+
+The branch location configuration file, locations.conf
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+``locations.conf`` allows one to specify overriding settings for
+a specific branch. The format is almost identical to the default section in
+bazaar.conf with one significant change: The section header, instead of saying
+default, will be the path to a branch that you wish to override a value
+for. The '?' and '*' wildcards are supported::
+
+    [/home/jdoe/branches/nethack]
+    email = Nethack Admin <nethack@nethack.com>
+
+    [http://hypothetical.site.com/branches/devel-branch]
+    create_signatures = always
+
+The authentication configuration file, authentication.conf
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+``authentication.conf`` allows one to specify credentials for
+remote servers. This can be used for all the supported transports and any part
+of bzr that requires authentication (smtp for example).
+
+The syntax of the file obeys the same rules as the others except for the
+option policies which don't apply.
+
+For more information on the possible uses of the authentication configuration
+file see :doc:`authentication-help`.
+
+
+Common options
+--------------
+
+debug_flags
+~~~~~~~~~~~
+
+A comma-separated list of debugging options to turn on.  The same values
+can be used as with the -D command-line option (see `help global-options`).
+For example::
+
+    debug_flags = hpss
+
+or::
+
+    debug_flags = hpss,evil
+
+email
+~~~~~
+
+The email address to use when committing a branch. Typically takes the form
+of::
+
+    email = Full Name <account@hostname.tld>
+
+editor
+~~~~~~
+
+The path of the editor that you wish to use if *bzr commit* is run without
+a commit message. This setting is trumped by the environment variable
+``BZR_EDITOR``, and overrides the ``VISUAL`` and ``EDITOR`` environment
+variables.
+
+log_format
+~~~~~~~~~~
+
+The default log format to use. Standard log formats are ``long``, ``short``
+and ``line``. Additional formats may be provided by plugins. The default
+value is ``long``.
+
+check_signatures
+~~~~~~~~~~~~~~~~
+
+Reserved for future use.  These options will allow a policy for branches to
+require signatures.
+
+require
+    The gnupg signature for revisions must be present and must be valid.
+
+ignore
+    Do not check gnupg signatures of revisions.
+
+check-available
+    (default) If gnupg signatures for revisions are present, check them.
+    Bazaar will fail if it finds a bad signature, but will not fail if
+    no signature is present.
+
+create_signatures
+~~~~~~~~~~~~~~~~~
+
+Defines the behaviour of signing revisions on commits.  By default bzr will not
+sign new commits.
+
+always
+    Sign every new revision that is committed.  If the signing fails then the
+    commit will not be made.
+
+when-required
+    Reserved for future use.
+
+never
+    Reserved for future use.
+
+In future it is planned that ``when-required`` will sign newly
+committed revisions only when the branch requires them.  ``never`` will refuse
+to sign newly committed revisions, even if the branch requires signatures.
+
+dirstate.fdatasync
+~~~~~~~~~~~~~~~~~~
+
+If true (default), working tree metadata changes are flushed through the
+OS buffers to physical disk.  This is somewhat slower, but means data
+should not be lost if the machine crashes.  See also repository.fdatasync.
+
+gpg_signing_key
+~~~~~~~~~~~~~~~
+
+The GnuPG user identity to use when signing commits.  Can be an e-mail
+address, key fingerprint or full key ID.  When unset or when set to
+"default" Bazaar will use the user e-mail set with ``whoami``.
+
+recurse
+~~~~~~~
+
+Only useful in ``locations.conf``. Defines whether or not the
+configuration for this section applies to subdirectories:
+
+true
+    (default) This section applies to subdirectories as well.
+
+false
+    This section only applies to the branch at this directory and not
+    branches below it.
+
+gpg_signing_command
+~~~~~~~~~~~~~~~~~~~
+
+(Default: "gpg"). Which program should be used to sign and check revisions.
+For example::
+
+    gpg_signing_command = /usr/bin/gnpg
+
+The specified command must accept the options "--clearsign" and "-u <email>".
+
+bzr_remote_path
+~~~~~~~~~~~~~~~
+
+(Default: "bzr").  The path to the command that should be used to run the smart
+server for bzr.  This value may only be specified in locations.conf, because:
+
+- it's needed before branch.conf is accessible
+- allowing remote branch.conf files to specify commands would be a security
+  risk
+
+It is overridden by the BZR_REMOTE_PATH environment variable.
+
+smtp_server
+~~~~~~~~~~~
+
+(Default: "localhost"). SMTP server to use when Bazaar needs to send
+email, eg. with ``merge-directive --mail-to``, or the bzr-email plugin.
+
+smtp_username, smtp_password
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+User and password to authenticate to the SMTP server. If smtp_username
+is set, and smtp_password is not, Bazaar will prompt for a password.
+These settings are only needed if the SMTP server requires authentication
+to send mail.
+
+locks.steal_dead
+~~~~~~~~~~~~~~~~
+
+If set to true, bzr will automatically break locks held by processes from
+the same machine and user that are no longer alive.  Otherwise, it will
+print a message and you can break the lock manually, if you are satisfied
+the object is no longer in use.
+
+mail_client
+~~~~~~~~~~~
+
+A mail client to use for sending merge requests.
+By default, bzr will try to use ``mapi`` on Windows.  On other platforms, it
+will try ``xdg-email``. If either of these fails, it will fall back to
+``editor``.
+
+Supported values for specific clients:
+
+:claws: Use Claws.  This skips a dialog for attaching files.
+:evolution: Use Evolution.
+:kmail: Use KMail.
+:mutt: Use Mutt.
+:thunderbird: Use Mozilla Thunderbird or Icedove.  For Thunderbird/Icedove 1.5,
+    this works around some bugs that xdg-email doesn't handle.
+
+Supported generic values are:
+
+:default: See above.
+:editor: Use your editor to compose the merge request.  This also uses
+    your commit id, (see ``bzr whoami``), smtp_server and (optionally)
+    smtp_username and smtp_password.
+:mapi: Use your preferred e-mail client on Windows.
+:xdg-email: Use xdg-email to run your preferred mail program
+
+repository.fdatasync
+~~~~~~~~~~~~~~~~~~~~
+
+If true (default), repository changes are flushed through the OS buffers
+to physical disk.  This is somewhat slower, but means data should not be
+lost if the machine crashes.  See also dirstate.fdatasync.
+
+submit_branch
+~~~~~~~~~~~~~
+
+The branch you intend to submit your current work to.  This is automatically
+set by ``bzr send``, and is also used by the ``submit:`` revision spec.  This
+should usually be set on a per-branch or per-location basis.
+
+public_branch
+~~~~~~~~~~~~~
+
+A publically-accessible version of this branch (implying that this version is
+not publically-accessible).  Used (and set) by ``bzr send``.
+
+suppress_warnings
+~~~~~~~~~~~~~~~~~
+
+A list of strings, each string represent a warning that can be emitted by
+bzr. Mentioning a warning in this list tells bzr to not emit it.
+
+Valid values:
+
+* ``format_deprecation``:
+    whether the format deprecation warning is shown on repositories that are
+    using deprecated formats.
+
+default_format
+~~~~~~~~~~~~~~
+
+A format name for the default format used when creating branches.  See ``bzr
+help formats`` for possible values.
+
+
+Unicode options
+---------------
+
+output_encoding
+~~~~~~~~~~~~~~~
+
+A Python unicode encoding name for text output from bzr, such as log
+information.  Values include: utf8, cp850, ascii, iso-8859-1.  The default
+is the terminal encoding prefered by the operating system.
+
+
+Branch type specific options
+----------------------------
+
+These options apply only to branches that use the ``dirstate-tags`` or
+later format.  They
+are usually set in ``.bzr/branch/branch.conf`` automatically, but may be
+manually set in ``locations.conf`` or ``bazaar.conf``.
+
+append_revisions_only
+~~~~~~~~~~~~~~~~~~~~~
+
+If set to "True" then revisions can only be appended to the log, not
+removed.  A branch with this setting enabled can only pull from another
+branch if the other branch's log is a longer version of its own.  This is
+normally set by ``bzr init --append-revisions-only``. If you set it
+manually, use either 'True' or 'False' (case-sensitive) to maintain
+compatibility with previous bzr versions (older than 2.2).
+
+parent_location
+~~~~~~~~~~~~~~~
+
+If present, the location of the default branch for pull or merge.  This option
+is normally set when creating a branch, the first ``pull`` or by ``pull
+--remember``.
+
+push_location
+~~~~~~~~~~~~~
+
+If present, the location of the default branch for push.  This option
+is normally set by the first ``push`` or ``push --remember``.
+
+push_strict
+~~~~~~~~~~~
+
+If present, defines the ``--strict`` option default value for checking
+uncommitted changes before pushing.
+
+dpush_strict
+~~~~~~~~~~~~
+
+If present, defines the ``--strict`` option default value for checking
+uncommitted changes before pushing into a different VCS without any
+custom bzr metadata.
+
+bound_location
+~~~~~~~~~~~~~~
+
+The location that commits should go to when acting as a checkout.
+This option is normally set by ``bind``.
+
+bound
+~~~~~
+
+If set to "True", the branch should act as a checkout, and push each commit to
+the bound_location.  This option is normally set by ``bind``/``unbind``.
+
+send_strict
+~~~~~~~~~~~
+
+If present, defines the ``--strict`` option default value for checking
+uncommitted changes before sending a merge directive.
+
+add.maximum_file_size
+~~~~~~~~~~~~~~~~~~~~~
+
+Defines the maximum file size the command line "add" operation will allow
+in recursive mode, with files larger than this value being skipped. You may 
+specify this value as an integer (in which case it is interpreted as bytes), 
+or you may specify the value using SI units, i.e. 10KB, 20MB, 1G. A value of 0 
+will disable skipping.
+
+External Merge Tools
+--------------------
+
+bzr.mergetool.<name>
+~~~~~~~~~~~~~~~~~~~~
+
+Defines an external merge tool called <name> with the given command-line.
+Arguments containing spaces should be quoted using single or double quotes. The
+executable may omit its path if it can be found on the PATH.
+
+The following markers can be used in the command-line to substitute filenames
+involved in the merge conflict::
+
+  {base}      file.BASE
+  {this}      file.THIS
+  {other}     file.OTHER
+  {result}    output file
+  {this_temp} temp copy of file.THIS, used to overwrite output file if merge
+              succeeds.
+
+For example::
+
+  bzr.mergetool.kdiff3 = kdiff3 {base} {this} {other} -o {result}
+
+bzr.default_mergetool
+~~~~~~~~~~~~~~~~~~~~~
+
+Specifies which external merge tool (as defined above) should be selected by
+default in tools such as ``bzr qconflicts``.
+
+For example::
+
+  bzr.default_mergetool = kdiff3
diff --git a/bzrlib/help_topics/en/conflict-types.txt b/bzrlib/help_topics/en/conflict-types.txt
new file mode 100644
index 0000000..7fe037c
--- /dev/null
+++ b/bzrlib/help_topics/en/conflict-types.txt
@@ -0,0 +1,377 @@
+Conflict Types
+==============
+
+Some operations, like merge, revert and pull, modify the contents of your
+working tree.  These modifications are programmatically generated, and so they
+may conflict with the current state of your working tree. 
+
+When conflicts are present in your working tree (as shown by ``bzr
+conflicts``), you should resolve them and then inform bzr that the conflicts
+have been resolved.
+
+Resolving conflicts is sometimes not obvious. Either because the user that
+should resolve them is not the one responsible for their occurrence, as is the
+case when merging other people's work or because some conflicts are presented
+in a way that is not easy to understand.
+
+Bazaar tries to avoid conflicts ; its aim is to ask you to resolve the
+conflict if and only if there's an actual conceptual conflict in the source
+tree.  Because Bazaar doesn't understand the real meaning of the files being
+versioned, it can, when faced with ambiguities, fall short in either direction
+trying to resolve the conflict itself. Many kinds of changes can be combined
+programmatically, but sometimes only a human can determine the right thing to
+do.
+
+When Bazaar generates a conflict, it adds information into the working tree to
+present the conflicting versions, and it's up to you to find the correct
+resolution.
+
+Whatever the conflict is, resolving it is roughly done in two steps:
+
+1. Modify the working tree content so that the conflicted item is now in the
+   state you want to keep, then
+
+2. Inform Bazaar that the conflict is now solved and ask to cleanup any
+   remaining generated information (``bzr resolve <item>``).
+
+For most conflict types, there are some obvious ways to modify the working
+tree and put it into the desired state. For some types of conflicts, Bazaar
+itself already made a choice, when possible.
+
+Yet, whether Bazaar makes a choice or not, there are some other simple but
+different ways to resolve the conflict.
+
+Each type of conflict is explained below, and the action which must be done to
+resolve the conflict is outlined.
+
+Various actions are available depending on the kind of conflict, for some of
+these actions, Bazaar can provide some help. In the end you should at least
+inform Bazaar that you're done with the conflict with::
+
+  ``bzr resolve FILE --action=done'
+
+Note that this is the default action when a single file is involved so you can
+simply use::
+
+   ``bzr resolve FILE``
+
+See ``bzr help resolve`` for more details.
+
+Text conflicts
+--------------
+
+Typical message::
+
+  Text conflict in FILE
+
+These are produced when a text merge cannot completely reconcile two sets of
+text changes.  Bazaar will emit files for each version with the extensions
+THIS, OTHER, and BASE.  THIS is the version of the file from the target tree,
+i.e. the tree that you are merging changes into.  OTHER is the version that you
+are merging into the target.  BASE is an older version that is used as a basis
+for comparison.
+
+In the main copy of the file, Bazaar will include all the changes that it
+could reconcile, and any un-reconciled conflicts are surrounded by
+"herringbone" markers like ``<<<<<<<``.
+
+Say the initial text is "The project leader released it.", and THIS modifies it
+to "Martin Pool released it.", while OTHER modifies it to "The project leader
+released Bazaar."  A conflict would look like this::
+
+  <<<<<<< TREE
+  Martin Pool released it.
+  =======
+  The project leader released Bazaar.
+  >>>>>>> MERGE-SOURCE
+
+The correct resolution would be "Martin Pool released Bazaar."
+
+You can handle text conflicts either by editing the main copy of the file,
+or by invoking external tools on the THIS, OTHER and BASE versions.  It's
+worth mentioning that resolving text conflicts rarely involves picking one
+set of changes over the other (but see below when you encounter these
+cases).  More often, the two sets of changes must be intelligently combined.
+
+If you edit the main copy, be sure to remove the herringbone markers.  When
+you are done editing, the file should look like it never had a conflict, and be
+ready to commit.
+
+When you have resolved text conflicts, just run ``bzr resolve --auto``, and
+Bazaar will auto-detect which conflicts you have resolved.
+
+When the conflict is resolved, Bazaar deletes the previously generated
+``.BASE``, ``.THIS`` and ``.OTHER`` files if they are still present in the
+working tree.
+
+
+When you want to pick one set of changes over the other, you can use ``bzr
+resolve`` with one of the following actions:
+
+* ``--action=take-this`` will issue ``mv FILE.THIS FILE``,
+* ``--action=take-other`` will issue ``mv FILE.OTHER FILE``.
+
+Note that if you have modified ``FILE.THIS`` or ``FILE.OTHER``, these
+modifications will be taken into account.
+
+Content conflicts
+-----------------
+
+Typical message::
+
+  Contents conflict in FILE
+
+This conflict happens when there are conflicting changes in the working tree
+and the merge source, but the conflicted items are not text files.  They may
+be binary files, or symlinks, or directories.  It can even happen with files
+that are deleted on one side, and modified on the other.
+
+Like text conflicts, Bazaar will emit THIS, OTHER and BASE files.  (They may be
+regular files, symlinks or directories).  But it will not include a "main copy"
+of the file with herringbone conflict markers.  It will appear that the "main
+copy" has been renamed to THIS or OTHER.
+
+To resolve that kind of conflict, you should rebuild FILE from either version
+or a combination of both.
+
+``bzr resolve`` recognizes the following actions:
+
+* ``--action=take-this`` will issue ``bzr mv FILE.THIS FILE``,
+* ``--action=take-other`` will issue ``bzr mv FILE.OTHER FILE``,
+* ``--action=done`` will just mark the conflict as resolved.
+
+Any action will also delete the previously generated ``.BASE``, ``.THIS`` and
+``.OTHER`` files if they are still present in the working tree.
+
+Bazaar cannot auto-detect when conflicts of this kind have been resolved.
+
+Tag conflicts
+-------------
+
+Typical message::
+
+  Conflicting tags:
+      version-0.1
+
+When pulling from or pushing to another branch, Bazaar informs you about tags
+that conflict between the two branches; that is the same tag points to two
+different revisions.  You need not resolve these conflicts, but subsequent
+uses of pull or push will result in the same message.
+
+To resolve the conflict, you must apply the correct tags to either the target
+branch or the source branch as appropriate.  Use "bzr tags --show-ids -d
+SOURCE_URL" to see the tags in the source branch.  If you want to make the
+target branch's tags match the source branch, then in the target branch do
+``bzr tag --force -r revid:REVISION_ID CONFLICTING_TAG`` for each of the
+CONFLICTING_TAGs, where REVISION_ID comes from the list of tags in the source
+branch.  You need not call "bzr resolve" after doing this.  To resolve in
+favor of the target branch, you need to similarly use ``tag --force`` in the
+source branch.  (Note that pulling or pushing using --overwrite will overwrite
+all tags as well.)
+
+Duplicate paths
+---------------
+
+Typical message::
+
+  Conflict adding file FILE.  Moved existing file to FILE.moved.
+
+Sometimes Bazaar will attempt to create a file using a pathname that has
+already been used.  The existing file will be renamed to "FILE.moved".  
+
+To resolve that kind of conflict, you should rebuild FILE from either version
+or a combination of both.
+
+``bzr resolve`` recognizes the following actions:
+
+* ``--action=take-this`` will issue ``bzr rm FILE ; bzr mv FILE.moved FILE``,
+* ``--action=take-other`` will issue ``bzr rm FILE.moved``,
+* ``--action=done`` will just mark the conflict as resolved.
+
+Note that you must get rid of FILE.moved before using ``--action=done``.
+
+Bazaar cannot auto-detect when conflicts of this kind have been resolved.
+
+Unversioned parent
+------------------
+
+Typical message::
+
+    Conflict because FILE is not versioned, but has versioned children.
+
+Sometimes Bazaar will attempt to create a file whose parent directory is not
+versioned.  This happens when the directory has been deleted in the target,
+but has a new child in the source, or vice versa.  In this situation, Bazaar
+will version the parent directory as well.  Resolving this issue depends
+very much on the particular scenario.  You may wish to rename or delete either
+the file or the directory.  When you are satisfied, you can run "bzr resolve
+FILE" to mark the conflict as resolved.
+
+Missing parent
+--------------
+
+Typical message::
+
+  Conflict adding files to FILE.  Created directory.
+
+This happens when a directory has been deleted in the target, but has new
+children in the source.  This is similar to the "unversioned parent" conflict,
+except that the parent directory does not *exist*, instead of just being
+unversioned.  In this situation, Bazaar will create the missing parent.
+Resolving this issue depends very much on the particular scenario.
+
+To resolve that kind of conflict, you should either remove or rename the
+children or the directory or a combination of both.
+
+``bzr resolve`` recognizes the following actions:
+
+* ``--action=take-this`` will issue ``bzr rm directory`` including the
+  children,
+* ``--action=take-other`` will acknowledge Bazaar choice to keep the children
+  and restoring the directory,
+* ``--action=done`` will just mark the conflict as resolved.
+
+Bazaar cannot auto-detect when conflicts of this kind have been resolved.
+
+Deleting parent
+---------------
+
+Typical message::
+
+  Conflict: can't delete DIR because it is not empty.  Not deleting.
+
+This is the opposite of "missing parent".  A directory is deleted in the
+source, but has new children in the target (either because a directory
+deletion is merged or because the merge introduce new children).  Bazaar
+will retain the directory.  Resolving this issue depends very much on the
+particular scenario.
+
+To resolve that kind of conflict, you should either remove or rename the
+children or the directory or a combination of both.
+
+``bzr resolve`` recognizes the following actions:
+
+* ``--action=take-this`` will acknowledge Bazaar choice to keep the directory,
+
+* ``--action=take-other`` will issue ``bzr rm directory`` including the 
+  children,
+
+* ``--action=done`` will just mark the conflict as resolved.
+
+Note that when merging a directory deletion, if unversioned files are
+present, they become potential orphans has they don't have a directory
+parent anymore.
+
+Handling such orphans, *before* the conflict is created, is controlled by
+setting the ``bzr.transform.orphan_policy`` configuration option.
+
+There are two possible values for this option:
+
+* ``conflict`` (the default): will leave the orphans in place and
+  generate a conflicts,
+
+* ``move``: will move the orphans to a ``bzr-orphans`` directory at the root
+  of the working tree with names like ``<file>.~#~``.
+
+Bazaar cannot auto-detect when conflicts of this kind have been resolved.
+
+Path conflict
+-------------
+
+Typical message::
+
+  Path conflict: PATH1 / PATH2
+
+This happens when the source and target have each modified the name or parent
+directory of a file.  Bazaar will use the path elements from the source.
+
+To resolve that kind of conflict, you just have to decide what name should be
+retained for the file involved.
+
+``bzr resolve`` recognizes the following actions:
+
+* ``--action=take-this`` will revert Bazaar choice and keep ``PATH1`` by
+  issuing ``bzr mv PATH2 PATH1``,
+* ``--action=take-other`` will acknowledge Bazaar choice of keeping ``PATH2``,
+* ``--action=done`` will just mark the conflict as resolved.
+
+Bazaar cannot auto-detect when conflicts of this kind have been resolved.
+
+Parent loop
+-----------
+
+Typical message::
+
+  Conflict moving FILE into DIRECTORY.  Cancelled move.
+
+This happens when the source and the target have each moved directories, so
+that, if the change could be applied, a directory would be contained by itself.
+For example::
+
+  $ bzr init
+  $ bzr mkdir white
+  $ bzr mkdir black
+  $ bzr commit -m "BASE"
+  $ bzr branch . ../other
+  $ bzr mv white black
+  $ bzr commit -m "THIS"
+  $ bzr mv ../other/black ../other/white
+  $ bzr commit ../other -m "OTHER"
+  $ bzr merge ../other
+
+In this situation, Bazaar will cancel the move, and leave ``white`` in
+``black``.  To resolve that kind of conflict, you just have to decide what
+name should be retained for the directories involved.
+
+``bzr resolve`` recognizes the following actions:
+
+* ``--action=take-this`` will acknowledge Bazaar choice of leaving ``white`` 
+  in ``black``,
+* ``--action=take-other`` will revert Bazaar choice and move ``black`` in
+   ``white`` by issuing ``bzr mv black/white white ; bzr mv black white``,
+* ``--action=done`` will just mark the conflict as resolved.
+
+Bazaar cannot auto-detect when conflicts of this kind have been resolved.
+
+Non-directory parent
+--------------------
+
+Typical message::
+
+  Conflict: foo.new is not a directory, but has files in it.
+  Created directory.
+
+This happens when one side has added files to a directory, and the other side
+has changed the directory into a file or symlink.  For example::
+
+  $ bzr init
+  $ bzr mkdir foo
+  $ bzr commit -m "BASE"
+  $ bzr branch . ../other
+  $ rmdir foo
+  $ touch foo
+  $ bzr commit -m "THIS"
+  $ bzr mkdir ../other/foo/bar
+  $ bzr commit ../other -m "OTHER"
+  $ bzr merge ../other
+
+To resolve that kind of conflict, you have to decide what name should be
+retained for the file, directory or symlink involved.
+
+``bzr resolve`` recognizes the following actions:
+
+* ``--action=take-this`` will issue ``bzr rm --force foo.new`` and 
+  ``bzr add foo``,
+* ``--action=take-other`` will issue ``bzr rm --force foo`` and 
+  ``bzr mv foo.new foo``,
+* ``--action=done`` will just mark the conflict as resolved.
+
+Bazaar cannot auto-detect when conflicts of this kind have been resolved.
+
+MalformedTransform
+------------------
+
+It is possible (though very rare) for Bazaar to raise a MalformedTransform
+exception.  This means that Bazaar encountered a filesystem conflict that it was
+unable to resolve.  This usually indicates a bug.  Please let us know if you
+encounter this.  Our bug tracker is at https://launchpad.net/bzr/+bugs
diff --git a/bzrlib/help_topics/en/content-filters.txt b/bzrlib/help_topics/en/content-filters.txt
new file mode 100644
index 0000000..8abe5a6
--- /dev/null
+++ b/bzrlib/help_topics/en/content-filters.txt
@@ -0,0 +1,93 @@
+Content Filters
+===============
+
+Content formats
+---------------
+
+Bazaar's content filtering allows you to store files in a different
+format from the copy in your working tree.  This lets you, or your
+co-developers, use Windows development tools that expect CRLF files
+on projects that use other line-ending conventions. Among other things,
+content filters also let Unix developers more easily work on projects
+using Windows line-ending conventions, keyword expansion/compression,
+and trailing spaces on lines in text files to be implicitly stripped
+when committed.
+
+To generalize, there are two content formats supported by Bazaar:
+
+* a canonical format - how files are stored internally
+* a convenience format - how files are created in a working tree.
+
+
+Format conversion
+-----------------
+
+The conversion between these formats is done by content filters.
+A content filter has two parts:
+
+* a read converter - converts from convenience to canonical format
+* a write converter - converts from canonical to convenience format.
+
+Many of these converters will provide *round-trip* conversion,
+i.e. applying the read converter followed by the write converter
+gives back the original content. However, others may provide an
+asymmetric conversion. For example, a read converter might strip
+trailing whitespace off lines in source code while the matching
+write converter might pass content through unchanged.
+
+
+Enabling content filters
+------------------------
+
+Content filters are typically provided by plugins, so the first step
+in using them is to install the relevant plugins and read their
+documentation. Some plugins may be very specific about which files
+they filter, e.g. only files ending in ``.java`` or ``.php``.
+In other cases, the plugin may leave it in the user's hands to
+define which files are to be filtered. This is typically done
+using rule-based preferences. See ``bzr help rules`` for general
+information about defining these.
+
+
+Impact on commands
+------------------
+
+Read converters are only applied to commands that read content from
+a working tree, e.g. status, diff and commit. For example, ``bzr diff``
+will apply read converters to files in the working tree, then compare
+the results to the content last committed.
+
+Write converters are only applied by commands that **create files in a
+working tree**, e.g. branch, checkout, update. If you wish to see the
+canonical format of a file or tree, use ``bzr cat`` or ``bzr export``
+respectively.
+
+Note: ``bzr commit`` does not implicitly apply write converters after
+comitting files. If this makes sense for a given plugin providing
+a content filter, the plugin can usually achieve this effect by using a
+``start_commit`` or ``post_commit`` hook say. See :doc:`hooks-help`
+for more information on hooks.
+
+
+Refreshing your working tree
+----------------------------
+
+For performance reasons, Bazaar caches the timestamps of files in
+a working tree, and assumes files are unchanged if their timestamps
+match the cached values. As a consequence, there are times when
+you may need to explicitly ask for content filtering to be reapplied
+in one or both directions, e.g. after installing or reconfiguring
+plugins providing it.
+
+Here are some general guidelines for doing this:
+
+ * To reapply read converters, ``touch`` files, i.e. update their
+   timestamp. Operations like ``bzr status`` should then reapply the
+   relevant read converters and compare the end result with the
+   canonical format.
+
+ * To reapply write converters, ensure there are no local changes,
+   delete the relevant files and run ``bzr revert`` on those files.
+
+Note: In the future, it is likely that additional options will be added
+to commands to make this refreshing process faster and safer.
diff --git a/bzrlib/help_topics/en/debug-flags.txt b/bzrlib/help_topics/en/debug-flags.txt
new file mode 100644
index 0000000..5446516
--- /dev/null
+++ b/bzrlib/help_topics/en/debug-flags.txt
@@ -0,0 +1,45 @@
+Debug Flags
+===========
+
+These flags can be passed on the bzr command line or (without the ``-D``
+prefix) put in the ``debug_flags`` variable in ``bazaar.conf``.
+
+-Dauth            Trace authentication sections used.
+-Dbytes           Print out how many bytes were transferred
+-Ddirstate        Trace dirstate activity (verbose!)
+-Derror           Instead of normal error handling, always print a traceback
+                  on error.
+-Devil            Capture call sites that do expensive or badly-scaling
+                  operations.
+-Dfetch           Trace history copying between repositories.
+-Dfilters         Emit information for debugging content filtering.
+-Dforceinvdeltas  Force use of inventory deltas during generic streaming fetch.
+-Dgraph           Trace graph traversal.
+-Dhashcache       Log every time a working file is read to determine its hash.
+-Dhooks           Trace hook execution.
+-Dhpss            Trace smart protocol requests and responses.
+-Dhpssdetail      More hpss details.
+-Dhpssvfs         Traceback on vfs access to Remote objects.
+-Dhttp            Trace http connections, requests and responses.
+-Dindex           Trace major index operations.
+-Dknit            Trace knit operations.
+-Dlock            Trace when lockdir locks are taken or released.
+-Dnoretry         If a connection is reset, fail immediately rather than
+                  retrying the request.
+-Dprogress        Trace progress bar operations.
+-Dmem_dump        Dump memory to a file upon an out of memory error.
+-Dmerge           Emit information for debugging merges.
+-Dno_apport       Don't use apport to report crashes.
+-Dno_activity 	  Don't show transport activity indicator in progress bar.
+-Dpack            Emit information about pack operations.
+-Drelock          Emit a message every time a branch or repository object is
+                  unlocked then relocked the same way.
+-Dsftp            Trace SFTP internals.
+-Dstatic_tuple    Error when a tuple is used where a StaticTuple is expected
+-Dstream          Trace fetch streams.
+-Dstrict_locks    Trace when OS locks are potentially used in a non-portable
+                  manner.
+-Dunlock          Some errors during unlock are treated as warnings.
+-DIDS_never       Never use InterDifferingSerializer when fetching.
+-DIDS_always      Always use InterDifferingSerializer to fetch if appropriate
+                  for the format, even for non-local fetches.
diff --git a/bzrlib/help_topics/en/diverged-branches.txt b/bzrlib/help_topics/en/diverged-branches.txt
new file mode 100644
index 0000000..c58b749
--- /dev/null
+++ b/bzrlib/help_topics/en/diverged-branches.txt
@@ -0,0 +1,39 @@
+Diverged Branches
+=================
+
+When Bazaar tries to push one branch onto another, it requires that the
+destination branch must be ready to receive the source branch.  If this isn't
+the case, then we say that the branches have ``diverged``.  Branches are
+considered diverged if the destination branch's most recent commit is one that
+has not been merged (directly or indirectly) by the source branch.  To recover
+from diverged branches, one must merge the missing revisions into the source
+branch.
+
+This situation commonly arises when using a centralized workflow with local
+commits.  If someone else has committed new work to the mainline since your
+last pull and you have local commits that have not yet been pushed to the
+mainline, then your local branch and the mainline have diverged.
+
+Discovering What Has Diverged
+-----------------------------
+
+The ``bzr missing`` command is used to find out what revisions are in another
+branch that are not present in the current branch, and vice-versa.  It shows a
+summary of  which extra revisions exist in each branch.  If you want to see the
+precise effects of those revisions, you can use ``bzr diff --old=other_branch``
+to show the differences between other_branch and your current branch.
+
+A Solution
+----------
+
+The solution is to merge the revisions from the mainline into your local
+branch.  To do so, use ``bzr merge`` to get the new revisions from the
+mainline.  This merge may result in conflicts if the other developer's changes
+overlap with your changes.  These conflicts should be resolved before
+continuing. After any conflicts have been resolved, or even if there were no
+conflicts, Bazaar requires that you explicitly commit these new revisions
+to your local branch.  This requirement gives you an opportunity to test the
+resulting working tree for correctness, since the merged revisions could have
+made arbitrary changes.  After testing, you should commit the merge using
+``bzr commit``.  This clears up the diverged branches situation.  Your local
+branch can now be pushed to the mainline.
diff --git a/bzrlib/help_topics/en/eol.txt b/bzrlib/help_topics/en/eol.txt
new file mode 100644
index 0000000..d329d2b
--- /dev/null
+++ b/bzrlib/help_topics/en/eol.txt
@@ -0,0 +1,122 @@
+End of Line Conversion
+======================
+
+EOL conversion is provided as a content filter where Bazaar internally
+stores a canonical format but outputs a convenience format. See
+``bzr help content-filters`` for general information about using these.
+
+Note: Content filtering is only supported in recently added formats,
+e.g. 1.14. Be sure that both the repository *and* the branch are
+in a recent format. (Just setting the format on the repository
+is not enough.) If content filtering does not appear to be working, use
+'bzr info -v' to confirm that the branch is using "Working tree format 5"
+or later.
+
+EOL conversion needs to be enabled for selected file patterns using
+rules. See ``bzr help rules`` for general information on defining rules.
+Currently, rules are only supported in $BZR_HOME/.bazaar/rules (or
+%BZR_HOME%/bazaar/2.0/rules on Windows). Branch specific rules will be
+supported in a future verison of Bazaar.
+
+To configure which files to filter, set ``eol`` to one of the values below.
+(If a value is not set, ``exact`` is the default.)
+
+ ========== ===================================== ======================
+ Value      Checkout end-of-lines as              Commit end-of-lines as
+ ========== ===================================== ======================
+ ``native`` ``crlf`` on Windows, ``lf`` otherwise ``lf``
+ ---------- ------------------------------------- ----------------------
+ ``lf``     ``lf``                                ``lf``
+ ---------- ------------------------------------- ----------------------
+ ``crlf``   ``crlf``                              ``lf``
+ ---------- ------------------------------------- ----------------------
+ ``exact``  No conversion                         Exactly as in file
+ ========== ===================================== ======================
+
+Note: For safety reasons, no conversion is applied to any file where a null
+byte is detected in the file.
+
+For users working on a cross-platform project, here is a suggested rule
+to use as a starting point::
+
+  [name *]
+  eol = native
+
+If you have binary files that do not contain a null byte though, be
+sure to add ``eol = exact`` rules for those as well. You can do this
+by giving more explicit patterns earlier in the rules file. For example::
+
+  [name *.png]
+  eol = exact
+
+  [name *]
+  eol = native
+
+If your working tree is on a network drive shared by users on different
+operating systems, you typically want to force certain conventions for
+certain files. In that way, if a file is created with the wrong line
+endings or line endings get mixed during editing, it gets committed
+correctly and gets checked out correctly. For example::
+
+  [name *.bat]
+  eol = crlf
+
+  [name *.sh]
+  eol = lf
+
+  [name *]
+  eol = native
+
+If you take the care to create files with their required endings, you can
+achieve *almost* the same thing by using ``eol = exact``. It is slightly
+safer to use ``lf`` and ``crlf`` though because edits accidentally
+introducing mixed line endings will be corrected during commit for files
+with those settings.
+
+If you have sample test data that deliberately has text files with mixed
+newline conventions, you can ask for those to be left alone like this::
+
+  [name test_data/]
+  eol = exact
+
+  [name *]
+  eol = native
+
+Note that ``exact`` does not imply the file is binary but it does mean
+that no conversion of end-of-lines will be done. (Bazaar currently relies
+of content analysis to detect binary files for commands like ``diff``.
+In the future, a ``binary = true`` rule may be added but it is not
+supported yet.)
+
+If you have an existing repository with text files already stored using
+Windows newline conventions (``crlf``), then you may want to keep using that
+convention in the repository. Forcing certain files to this convention
+may also help users who do not have rules configured. To do this, set
+``eol`` to one of the values below.
+
+ ============================ ======================== ======================
+ Value                        Checkout end-of-lines as Commit end-of-lines as
+ ============================ ======================== ======================
+ ``native-with-crlf-in-repo`` ``crlf`` on Windows,     ``crlf``
+                              ``lf`` otherwise
+ ---------------------------- ------------------------ ----------------------
+ ``lf-with-crlf-in-repo``     ``lf``                   ``crlf``
+ ---------------------------- ------------------------ ----------------------
+ ``crlf-with-crlf-in-repo``   ``crlf``                 ``crlf``
+ ============================ ======================== ======================
+
+For users working on an existing project that uses Windows newline
+conventions in their Bazaar repository, this rule is suggested as a
+starting point::
+
+  [name *]
+  eol = native-with-crlf-in-repo
+
+For new projects, it is recommended that end-of-lines be stored as ``lf``
+and that users stick to the basic settings, i.e. ``native``, ``lf``,
+``crlf`` and ``exact``.
+
+Note: Bazaar's EOL conversion will convert the content of files but
+never reject files because a given line ending or mixed line endings
+are found. A precommit hook should be used if you wish to validate
+(and not just convert) content before committing.
diff --git a/bzrlib/help_topics/en/log-formats.txt b/bzrlib/help_topics/en/log-formats.txt
new file mode 100644
index 0000000..5cb7359
--- /dev/null
+++ b/bzrlib/help_topics/en/log-formats.txt
@@ -0,0 +1,34 @@
+Log Formats
+===========
+
+A log format controls how information about each revision is displayed.
+The standard log formats are compared below::
+
+  Feature                 long           short         line
+  ----------------------  -------------  ------------  -------------------
+  design goal             detailed view  concise view  1 revision per line
+  committer               name+email     name only     name only
+  author                  name+email     -             -
+  date-time format        full           date only     date only
+  commit message          full           full          top line
+  tags                    yes            yes           yes
+  merges indicator        -              yes           -
+  status/delta            optional       optional      -
+  diff/patch              optional       optional      -
+  revision-id             optional       optional      -
+  branch nick             yes            -             -
+  foreign vcs properties  yes            yes           -
+  preferred levels        all            1             1
+  digital signature       optional       -             -
+
+The default format is ``long``. To change this, define the ``log_format``
+setting in the ``[DEFAULT]`` section of ``bazaar.conf`` like this (say)::
+
+  [DEFAULT]
+  log_format = short
+
+Alternatively, to change the log format used for a given query, use the
+--long, --short or --line options.
+
+If one of the standard log formats does not meet your needs, additional
+formats can be provided by plugins.
diff --git a/bzrlib/help_topics/en/patterns.txt b/bzrlib/help_topics/en/patterns.txt
new file mode 100644
index 0000000..6250d20
--- /dev/null
+++ b/bzrlib/help_topics/en/patterns.txt
@@ -0,0 +1,38 @@
+Patterns
+========
+
+Bazaar uses patterns to match files at various times. For example,
+the ``add`` command skips over files that match ignore patterns
+and preferences can be associated with files using rule patterns.
+The pattern syntax is described below.
+
+Trailing slashes on patterns are ignored. If the pattern contains a
+slash or is a regular expression, it is compared to the whole path
+from the branch root. Otherwise, it is compared to only the last
+component of the path. To match a file only in the root directory,
+prepend ``./``. Patterns specifying absolute paths are not allowed.
+
+Patterns may include globbing wildcards such as::
+
+  ? - Matches any single character except '/'
+  * - Matches 0 or more characters except '/'
+  /**/ - Matches 0 or more directories in a path
+  [a-z] - Matches a single character from within a group of characters
+
+Patterns may also be `Python regular expressions`_. Regular expression
+patterns are identified by a ``RE:`` prefix followed by the regular
+expression.  Regular expression patterns may not include named or
+numbered groups.
+
+Case insensitive ignore patterns can be specified with regular expressions
+by using the ``i`` (for ignore case) flag in the pattern.
+
+For example, a case insensitive match for ``foo`` may be specified as::
+
+  RE:(?i)foo
+
+Ignore patterns may be prefixed with ``!``, which means that a filename
+matched by that pattern will not be ignored.
+
+.. _Python regular expressions: http://docs.python.org/library/re.html
+
diff --git a/bzrlib/help_topics/en/rules.txt b/bzrlib/help_topics/en/rules.txt
new file mode 100644
index 0000000..1bb01d0
--- /dev/null
+++ b/bzrlib/help_topics/en/rules.txt
@@ -0,0 +1,40 @@
+Rules
+=====
+
+Introduction
+------------
+
+Rules are defined in ini file format where the sections are file glob
+patterns and the contents of each section are the preferences for files
+matching that pattern(s). For example::
+
+    [name *.bat]
+    eol = native
+
+    [name *.html *.xml]
+    keywords = xml_escape
+
+Preferences like these are useful for commands and plugins wishing to
+provide custom behaviour for selected files.  For more information on 
+end of line conversion see :doc:`eol-help`.
+Keyword support is provided by the `keywords plugin
+<http://doc.bazaar.canonical.com/plugins/en/keywords-plugin.html>`_.
+
+Files
+-----
+
+Default rules for all branches are defined in the optional file
+``BZR_HOME/rules``. 
+
+Rule Patterns
+-------------
+
+Patterns are ordered and searching stops as soon as one matches.
+As a consequence, more explicit patterns should be placed towards
+the top of the file. Rule patterns use exactly the same conventions
+as ignore patterns. See :doc:`patterns-help` for details.
+
+.. note::
+
+   Patterns containing square brackets or spaces should be
+   surrounded in quotes to ensure they are correctly parsed.
diff --git a/bzrlib/help_topics/en/url-special-chars.txt b/bzrlib/help_topics/en/url-special-chars.txt
new file mode 100644
index 0000000..2e528b8
--- /dev/null
+++ b/bzrlib/help_topics/en/url-special-chars.txt
@@ -0,0 +1,48 @@
+Special character handling in URLs
+==================================
+
+Bazaar allows locations to be specified in multiple ways, either:
+
+ * Fully qualified URLs
+
+ * File system paths, relative or absolute
+
+Internally bzr treats all locations as URLs. For any file system paths
+that are specified it will automatically determine the appropriate URL
+representation, and escape special characters where necessary.
+
+There are a few characters which have special meaning in URLs and need careful
+handling to avoid ambiguities. Characters can be escaped with a % and a hex
+value in URLs. Any non-ASCII characters in a file path will automatically be
+urlencoded when the path is converted to a URL.
+
+URLs represent non-ASCII characters in an encoding defined by the server, but
+usually UTF-8.  The % escapes should be of the UTF-8 bytes.  Bazaar tries to be
+generous in what it accepts as a URL and to print them in a way that
+will be readable.
+
+For example, if you have a directory named '/tmp/%2False' these are all valid
+ways of accessing the content (0x2F, or 47, is the ASCII code for forward slash)::
+
+  cd /tmp
+  bzr log /tmp/%2False
+  bzr log %2False
+  bzr log file:///tmp/%252False
+  bzr log file://localhost/tmp/%252False
+  bzr log file:%252False
+
+These are valid but do not refer to the same file::
+
+  bzr log file:///tmp/%2False (refers to a file called /tmp/\/alse)
+  bzr log %252False (refers to a file called /tmp/%252False)
+
+Comma also has special meaning in URLs, because it denotes `segment parameters`_
+
+_`segment parameters`: http://www.ietf.org/rfc/rfc3986.txt (section 3.3)
+
+Comma is also special in any file system paths that are specified. To use a literal
+comma in a file system path, specify a URL and URL encode the comma::
+
+  bzr log foo,branch=bla # path "foo" with the segment parameter "branch" set to "bla"
+  bzr log file:foo%2Cbranch=bla # path "foo,branch=bla"
+  bzr log file:foo,branch=bla # path "foo" with segment parameter "branch" set to "bla"
diff --git a/bzrlib/help_topics/es/conflict-types.txt b/bzrlib/help_topics/es/conflict-types.txt
new file mode 100644
index 0000000..9bed954
--- /dev/null
+++ b/bzrlib/help_topics/es/conflict-types.txt
@@ -0,0 +1,185 @@
+=====================
+Manejo de Conflictos
+=====================
+
+Algunas operaciones, como merge, revert y pull, modifican el contenido de su
+working tree. Estas modificaciones son generadas automaticamente, con lo cual
+pueden tener conflictos con el estado actual de su working tree.  Muchos tipos
+de cambios pueden ser combinados automaticamentem pero a veces solo algunos
+humanos pueden determinar la decision correcta a tomar.  Cuando esto sucede,
+Bazaar lo informara que hay un conflict y pedira que lo resuelva. El comando
+para resolverlo es ``resolve``, pero debe realizar alguna accion antes de
+ejecutarlo.
+
+Cada tipo de conflicto esta explicado a continuacion, y la accion que se debe
+realizar para resolver el conflicto esta detallada.
+
+
+Conflictos de Texto (Text conflicts)
+=====================================
+Mensaje comun::
+
+  Text conflict in ARCHIVO
+
+Estos se producen cuando el texto a unificar no puede ser completamente
+reconciliado entre dos cambios. Bazaar emitira archivos para cada version con
+extensiones THIS, OTHER, y BASE.  THIS es la version del archivo del tree
+de destino, por ejemplo, el tree al que estan unificando los cambios. OTHER
+es la version que estan uniendo al tree de destino. BASE es la version
+anterior que es usado como base para la comparacion.
+
+En la copia principal del archivo, Bazaar incluira los cambios que puede
+reconciliar, y cualquier cambio sin reconciliar son rodeados con marcadores
+"herringbone" como ``<<<<<<<``.
+
+Digamos que el texto inicial es "El lider del proyecto lo lanzo.", y THIS lo
+modifica a "Martin Pool lo lanzo.", mientras que OTHER lo modifica a "El lider
+del proyecto lanzo Bazaar."  Un conflicto se veria asi::
+
+  <<<<<<< TREE
+  Martin Pool lo lanzo.
+  =======
+  El lider del proyecto lanzo Bazaar.
+  >>>>>>> MERGE-SOURCE
+
+La resulucion correcta seria "Martin Pool lanzo Bazaar."
+
+Puede manejar conflictos de texto o editando la copia principal del archivo,
+o invocando herramientas externas on las versiones THIS, OTHER y BASE. Vale
+la pena mencionar que resolver conflictos de texto rara vez involucra elegir
+un conjunto de cambios u otros. Los mas comun es que tenga que combinar
+inteligentemente.
+
+Si modifica la copia principal, asegurese de sacar los marcadores "herringbone".
+Cuando termino de modificar, el archivo debe estar como si nunca hubiese estado
+con conflictos, y estar listo para hacer commit.
+
+Cuando resolvio los conflictos de texto, solo ejecute "bzr resolve", y Bazaar
+detectera automaticamente que resolvio.
+
+
+Conflictos de contenido (Content conflicts)
+============================================
+Mensaje comun::
+
+  Contents conflict in ARCHIVO
+
+Este conflicto sucede cuando hay cambios que crean conflictos en el tree de
+destino y el fuente a unificar, pero los items con conflictos no son archivos
+de texto.  Pueden ser archivos binarios, symlinks o directorios.  Pueden suceder
+con archivos que fueron eliminados en un lado, y modificados en el otro.
+
+Como los conflictos de texto, Bazaar creara archivos THIS, OTHER y BASE.
+(pueden ser archivos normales, symlinks o directorios).  Esto no incluira
+la "copia principal" del archivo con marcadores "herringbone".  Parecera que la
+"copia principal" fue renombrado a THIS o OTHER.
+
+Para resolver esto, utilice "bzr mv" para renombrar el archivo a su nombre
+original, y combine los cambios manualmente. Cuando este satisfecho, ejecute
+"bzr resolve ARCHIVO".  Bazaar no puede detectar cuando cambios de este tipo
+fueron resueltos.
+
+
+Rutas Duplicadas (Duplicate Paths)
+==================================
+Mensaje comun::
+
+  Conflict adding file ARCHIVO.  Moved existing file to ARCHIVO.moved.
+
+Bazaar a veces intentara crear un archivo usando la ruta que ya fue usada.
+El archivo existente ser renombrado a "ARCHIVO.moved".  Si lo desea, puede
+renombrar cualquiera de estos archivos, o combinar su contenido. Cuando
+este satisfecho, puede ejecutar "bzr resolve ARCHIVO" para marcar que el
+conflicto fue resuelto.
+
+
+Padre sin versionar (Unversioned Parent)
+========================================
+Mensajes comunes::
+
+    Conflict because ARCHIVO no esta versionado, pero tiene hijos versionados.
+
+A veces Bazaar intentara crear un archivo cuyo directorio padre no esta
+versionado. Esto sucede cuando el directorio fue eliminado en el destino,
+pero tiene un hijo nuevo en origen, o vice versa. En esta situacion, Bazaar
+versionara al directorio padre tambien.  Resolver este tema depende mucho
+en el escenario particular.  Puede que quiera renombrar o eliminar o renombrar
+cualquier archivo o directorio.  Cuando esta satisfecho, puede ejecutar "bzr
+resolve ARCHIVO" para marcar el conflicto como resuelto.
+
+
+Padre faltante (Missing Parent)
+===============================
+Mensaje comun::
+
+  Conflict adding files to ARCHIVO.  Created directory.
+
+Esto sucede cuando un archivo fue eliminado en el destino, pero tiene hijos
+en el origen.  Esto es similar al conflicto "Padre sin versionar", excepto
+que el directorio padre *no existe*, en vez de no estar versionado. En esta
+situacion, Bazaar creara al padre faltante.  Resolver estos temas depende
+mucho de cada caso particular. Usted puede querer renombrar o eliminar
+cualquiera de los archivos o directorios.  Cuando este satisfecho, puede
+ejecutar "bzr resolve ARCHIVO" para marcar al archivo resuelto.
+
+
+Borrando al Padre (Deleting Parent)
+===================================
+Mensaje comun::
+
+  Conflict: can't delete ARCHIVO because it is not empty.  Not deleting.
+
+Esto es el opuesto a "Padre faltante".  Un directorio es eliminado en el
+origen, pero tiene hijos en el destino.  Bazaar mantiene el directorio.
+Resolver este tema depende mucho de cada escenario particular.  Quizas quiera
+renombrar o eliminar cualquiera de los archivos o directorios.  Cuando esta
+satisfecho, puede ejecutar "bzr resolver ARCHIVO" para marcar al conflicto
+como resuelto.
+
+
+Conflicto de Ruta (Path Conflict)
+=================================
+Mensaje comun::
+
+  Path conflict: RUTA1 / RUTA2
+
+Esto sucede cuando en el origen y el destino han sido modificados el nombre
+o directorio padre de un archivo. Bazaar usara la ruta de los elementos del
+origen. Puede renombrar el archivo, y una vez que lo ha hecho, ejecutar
+"bzr resolve ARCHIVO" para marcarl el conflicto como resuelto.
+
+
+Bucle Padre (Parent Loop)
+=========================
+Mensaje comun::
+
+  Conflict moving ARCHIVO into DIRECTORIO.  Cancelled move.
+
+Esto sucede cuando en el origen y el destino se han movido directorios, de
+tal forma que, si se aplicaran los cambios, el directorios se contendria a
+si mismo.
+Por ejemplo::
+
+  $ bzr init
+  $ bzr mkdir a
+  $ bzr mkdir b
+  $ bzr commit -m "BASE"
+  $ bzr branch . ../other
+  $ bzr mv a b
+  $ bzr commit -m "THIS"
+  $ bzr mv ../other/b ../other/a
+  $ bzr commit ../other -m "OTHER"
+  $ bzr merge ../other
+
+En esta situacion, Bazaar cancelara el movimiento, y dejara "a" en "b".
+Puede renombrar los directorios como desee, y una vez que lo ha hecho,
+ejecute "bzr resolve ARCHIVO" para marcar el conflicto como resuelto.
+
+
+MalformedTransform
+==================
+Es posible (aunque muy raro) que Bazaar de una excepcion MalformedTransform.
+Esto quiere decir que Bazaar encontro un conflicto en el sistema de archivos
+que no le fue posible resolver.  Esto usualmente indica un bug.  Por favor
+haganoslo saber si se encuentra en esta situacion. Nuestro sistema de bugs
+se encuentra en https://launchpad.net/bzr/+bugs