Rev 5432: Add more doc and fix rst typos in file:///home/vila/src/bzr/bugs/323111-orphans/
Vincent Ladeuil
v.ladeuil+lp at free.fr
Fri Oct 15 12:10:34 BST 2010
At file:///home/vila/src/bzr/bugs/323111-orphans/
------------------------------------------------------------
revno: 5432
revision-id: v.ladeuil+lp at free.fr-20101015111034-2nyx66ypbgar0tx7
parent: v.ladeuil+lp at free.fr-20101015095629-1rijc8a2cgfz17pl
fixes bug(s): https://launchpad.net/bugs/660943
committer: Vincent Ladeuil <v.ladeuil+lp at free.fr>
branch nick: orphan-config-option
timestamp: Fri 2010-10-15 13:10:34 +0200
message:
Add more doc and fix rst typos
-------------- next part --------------
=== modified file 'bzrlib/help_topics/en/conflict-types.txt'
--- a/bzrlib/help_topics/en/conflict-types.txt 2010-04-28 13:15:14 +0000
+++ b/bzrlib/help_topics/en/conflict-types.txt 2010-10-15 11:10:34 +0000
@@ -26,13 +26,13 @@
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::
-
- - modify the working tree content so that the conflicted item is now in the
- state you want to keep,
-
- - inform Bazaar that the conflict is now solved and ask to cleanup any
- remaining generated information (``bzr resolve <item>``).
+Whatever the conflict is, resolving it is roughly done in two steps:
+
+- modify the working tree content so that the conflicted item is now in the
+ state you want to keep,
+
+- 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
@@ -126,9 +126,9 @@
``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.
+* ``--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.
@@ -172,11 +172,11 @@
To resolve that kind of conflict, you should rebuild FILE from either version
or a combination of both.
-``bzr resolve`` recognizes the following actions::
+``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.
+* ``--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``.
@@ -213,13 +213,13 @@
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::
+``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.
+* ``--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.
@@ -231,18 +231,37 @@
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. Bazaar will retain the directory.
-Resolving this issue depends very much on the particular scenario.
+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.
+``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:
+
+* ``never`` (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.
@@ -259,12 +278,12 @@
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::
+``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.
+* ``--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.
@@ -294,13 +313,13 @@
``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::
+``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
+* ``--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.
+* ``--action=done`` will just mark the conflict as resolved.
Bazaar cannot auto-detect when conflicts of this kind have been resolved.
@@ -329,13 +348,13 @@
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::
+``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.
+* ``--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.
=== modified file 'bzrlib/transform.py'
--- a/bzrlib/transform.py 2010-10-15 09:56:29 +0000
+++ b/bzrlib/transform.py 2010-10-15 11:10:34 +0000
@@ -1341,7 +1341,7 @@
# FIXME: There is no tree config, so we use the branch one (it's weird
# to define it this way as orphaning can only occur in a working tree,
# but that's all we have (for now). It will find the option in
- # locations,conf or bazaar.conf though) -- vila 20100916
+ # locations.conf or bazaar.conf though) -- vila 20100916
conf = self._tree.branch.get_config()
conf_var_name = 'bzrlib.transform.orphan_policy'
orphan_policy = conf.get_user_option(conf_var_name)
@@ -1406,7 +1406,7 @@
def refuse_orphan(tt, orphan_id, parent_id):
"""See TreeTransformBase.new_orphan.
- This refuses to create orphan, letting caller handle the conflict.
+ This refuses to create orphan, letting the caller handle the conflict.
"""
raise OrphaningForbidden('never')
=== modified file 'doc/en/release-notes/bzr-2.3.txt'
--- a/doc/en/release-notes/bzr-2.3.txt 2010-10-15 09:56:29 +0000
+++ b/doc/en/release-notes/bzr-2.3.txt 2010-10-15 11:10:34 +0000
@@ -181,6 +181,9 @@
* Correct the documentation for setting up the smart server with Apache.
(Neil Martinsen-Burrell, #311518)
+* Fix rst typos in bzrlib/help_topics/en/conflict-types.txt.
+ (Vincent Ladeuil, #660943)
+
* Provide more detailed help on the Launchpad plugin at "bzr help
plugins/launchpad". (Neil Martinsen-Burrell, #589379)
=== modified file 'doc/en/whats-new/whats-new-in-2.3.txt'
--- a/doc/en/whats-new/whats-new-in-2.3.txt 2010-10-15 09:56:29 +0000
+++ b/doc/en/whats-new/whats-new-in-2.3.txt 2010-10-15 11:10:34 +0000
@@ -95,13 +95,14 @@
**************************
* ``pull``, ``merge`` or ``switch`` can lead to conflicts when deleting a
- versioned directory contains unversioned files. This can now be avoided
- by setting the ``bzrlib.transform.orphan_policy`` configuration variable
- with a value of ``move``. In this case the unversioned files are moved to
- a ``bzr-orphans`` directory at the root of the working tree. The default
- behaviour is specified (if needed) by setting the variable to
- ``conflict``.
- (Vincent Ladeuil, #323111)
+ versioned directory contains unversioned files. The cause of the conflict
+ is that deleting the directory will orphan the unversioned files so the
+ user needs to instruct ``bzr`` what do to do about these orpahns. This
+ can is controlled by setting the ``bzr.transform.orphan_policy``
+ configuration variable with a value of ``move``. In this case the
+ unversioned files are moved to a ``bzr-orphans`` directory at the root of
+ the working tree. The default behaviour is specified (if needed) by
+ setting the variable to ``conflict``. (Vincent Ladeuil, #323111)
Documentation
*************
More information about the bazaar-commits
mailing list