Rev 4636: Moved Outline.txt into BRANCH.TODO. in file:///home/vila/src/bzr/experimental/conflict-manager/
Vincent Ladeuil
v.ladeuil+lp at free.fr
Tue Oct 27 16:18:30 GMT 2009
At file:///home/vila/src/bzr/experimental/conflict-manager/
------------------------------------------------------------
revno: 4636
revision-id: v.ladeuil+lp at free.fr-20091027161830-9ntgp27pq1rzhmyy
parent: v.ladeuil+lp at free.fr-20091027102821-u3f2l4tjee925rii
committer: Vincent Ladeuil <v.ladeuil+lp at free.fr>
branch nick: description
timestamp: Tue 2009-10-27 17:18:30 +0100
message:
Moved Outline.txt into BRANCH.TODO.
-------------- next part --------------
=== modified file 'BRANCH.TODO'
--- a/BRANCH.TODO 2009-05-06 05:36:28 +0000
+++ b/BRANCH.TODO 2009-10-27 16:18:30 +0000
@@ -3,3 +3,233 @@
#
#
+Related Bugs:
+=============
+
+https://bugs.edge.launchpad.net/bzr/+bug/414589
+
+https://bugs.edge.launchpad.net/bzr/+bug/236724
+https://bugs.edge.launchpad.net/bzr/+bug/228506
+https://bugs.edge.launchpad.net/bzr/+bug/113809
+https://bugs.edge.launchpad.net/bzr/+bug/322767
+https://bugs.edge.launchpad.net/bzr/+bug/416903
+https://bugs.edge.launchpad.net/bzr/+bug/355964
+
+https://bugs.edge.launchpad.net/bzr/+bug/257297
+https://bugs.edge.launchpad.net/bzr/+bug/232512
+
+https://bugs.edge.launchpad.net/bzr/+bug/405264
+
+
+TODO:
+=====
+
+- add more info to Conflict objects:
+ - base revid for text conflict
+ - this requires a format bump ?
+
+- tests with '.diverted' files ?
+
+- doc/es/user-guide/resolving_conflicts.txt is really
+ user-reference/resolving_conflicts.txt
+
+
+Overall presentation:
+=====================
+
+When conflicts are present in a working tree (as shown by ``bzr
+conflicts``), the user should resolve them and then inform bzr
+that the conflicts has 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 work
+or because some conflicts are presented in a way that is not easy
+to understand.
+
+``bzr`` try to avoid conflicts, its aim is to ask the user to
+resolve the conflict if and only if there's an actual conceptual
+conflict in the source tree. Because bzr doesn't understand the
+real meaning of the files being versioned it can fall short in
+either direction trying to resolve the conflict itself when faced
+with ambiguities.
+
+When it can't resolve, bzr add information into the working tree
+to present the conflicting versions and leave the resolution to
+the user.
+
+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 desired state, there are,
+
+- inform bzr 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 type
+of conflicts, bzr itself already made a choice when possible.
+
+Yet, whether bzr made a choice or not, there are some other ways
+simple but alternative ways to resolve the conflict.
+
+Providing the ``--interactive`` option to ``bzr resolve`` will
+display a short explanation of the conflict and propose some
+actions before marking the file as resolved.
+
+
+Design:
+=======
+
+The Conflict classes will receive additional methods to resolve
+the conflict in alternative ways.
+
+Resolve will receive a ``--interactive`` option and present a
+list of possible actions (including do nothing) to the user
+before marking the file as resolved.
+
+The --all and file* parameters will still be honored so that the
+user solve conflicts at his own pace.
+
+It should be possible for a GUI to query the conflict objects for
+possible actions (in textual form) and trigger them.
+
+
+Proposed actions by conflict type:
+==================================
+
+The following paragraphs list all the existing conflict types and summarize:
+- the actions that can be proposed to the user,
+- the cleanups that could remain to be done once the conflict is solved,
+
+In practice, the actions will always contain:
+- leave the user solve the conflict by its own means,
+- mark the conflict as solved without any additional action.
+
+
+Text conflicts:
+---------------
+
+5 ways:
+- force THIS (for all conflicted regions)
+- force OTHER (for all conflicted regions)
+- manually solve each conflicted region
+- force THIS (overriding all cleanly merged modifications)
+- force OTHER (overriding all cleanly merged modifications)
+
+resolve:
+- delete .THIS, .OTHER, .BASE if present
+
+Content conflicts:
+------------------
+
+3 ways:
+- bzr mv .THIS <item>,
+- bzr mv .OTHER <item>,
+- manually combine .THIS and .OTHER
+
+resolve:
+- delete .THIS, .OTHER, .BASE if present
+
+
+Duplicate paths
+---------------
+
+bzr made a choice
+
+3 ways:
+- bzr mv .moved <item> (refuse bzr choice)
+- bzr rm .moved (accept bzr choice)
+- manually combine <item> and .moved
+
+resolve:
+
+- nothing to do ? If the '.moved' file still exists emit a
+ warning ? Delete it ? Put it to the trash ?
+
+
+Unversioned parent
+------------------
+
+bzr made a choice: version the parent
+
+3 ways:
+- bzr rm <children>
+- bzr rm <parent>
+- manually rename <children>
+
+resolve:
+- nothing to do nothing more than the conflicted objects have been created
+
+
+Missing parent
+--------------
+
+bzr made a choice: create the missing parent and version it.
+
+3 ways:
+- bzr rm <children>
+- bzr rm <parent>
+- manually rename <children>
+
+resolve:
+- nothing to do, nothing more than the conflicted objects have been created
+
+
+Deleting parent
+---------------
+
+bzr made a choice: not delete the parent
+
+3 ways:
+- bzr rm <children>
+- bzr rm <parent>
+- manually solve the issue (may be more than a single children)
+
+resolve:
+- nothing to do
+
+
+Path conflict
+-------------
+
+bzr made a choice: use the source's name
+
+3 ways:
+- do nothing (accept bzr choice)
+- bzr mv <item> other-name (refuse bzr choice)
+- manually rename to a different name
+
+resolve:
+- nothing to do
+
+Parent loop
+-----------
+
+bzr made a choice: keep the existing renaming
+
+3 ways:
+- do nothing (accept bzr choice)
+- bzr mv this_parent/this_children other_parent/other_children
+- manually rename the items
+
+resolve:
+- nothing to do
+
+
+Non-directory parent
+--------------------
+
+bzr made a choice: create a <parent>.new directory
+
+There is no obvious single action that can solve the conflict
+here, but let's try anyway.
+
+3 ways:
+- bzr rm <parent>.new
+- bzr rm <parent> + bzr mv <parent>.new <parent>
+- manually rename the items
+
+resolve:
+- nothing to do
=== removed file 'Outline.txt'
--- a/Outline.txt 2009-10-16 12:54:42 +0000
+++ b/Outline.txt 1970-01-01 00:00:00 +0000
@@ -1,230 +0,0 @@
-Related Bugs:
-=============
-
-https://bugs.edge.launchpad.net/bzr/+bug/414589
-
-https://bugs.edge.launchpad.net/bzr/+bug/236724
-https://bugs.edge.launchpad.net/bzr/+bug/228506
-https://bugs.edge.launchpad.net/bzr/+bug/113809
-https://bugs.edge.launchpad.net/bzr/+bug/322767
-https://bugs.edge.launchpad.net/bzr/+bug/416903
-https://bugs.edge.launchpad.net/bzr/+bug/355964
-
-https://bugs.edge.launchpad.net/bzr/+bug/257297
-https://bugs.edge.launchpad.net/bzr/+bug/232512
-
-https://bugs.edge.launchpad.net/bzr/+bug/405264
-
-
-TODO:
-=====
-
-- add more info to Conflict objects:
- -
- - base revid for text conflict
-
-- tests with '.diverted' files ?
-
-- doc/es/user-guide/resolving_conflicts.txt is really
- use-reference/resolving_conflicts.txt
-
-
-Overall presentation:
-=====================
-
-When conflicts are present in a working tree (as shown by ``bzr
-conflicts``), the user should resolve them and then inform bzr
-that the conflicts has 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 work
-or because some conflicts are presented in a way that is not easy
-to understand.
-
-``bzr`` try to avoid conflicts, its aim is to ask the user to
-resolve the conflict if and only if there's an actual conceptual
-conflict in the source tree. Because bzr doesn't understand the
-real meaning of the files being versioned it can fall short in
-either direction trying to resolve the conflict itself when faced
-with ambiguities.
-
-When it can't resolve, bzr add information into the working tree
-to present the conflicting versions and leave the resolution to
-the user.
-
-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 desired state, there are,
-
-- inform bzr 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 type
-of conflicts, bzr itself already made a choice when possible.
-
-Yet, whether bzr made a choice or not, there are some other ways
-simple but alternative ways to resolve the conflict.
-
-Providing the ``--interactive`` option to ``bzr resolve`` will
-display a short explanation of the conflict and propose some
-actions before marking the file as resolved.
-
-
-Design:
-=======
-
-The Conflict classes will receive additional methods to resolve
-the conflict in alternative ways.
-
-Resolve will receive a ``--interactive`` option and present a
-list of possible actions (including do nothing) to the user
-before marking the file as resolved.
-
-The --all and file* parameters will still be honored so that the
-user solve conflicts at his own pace.
-
-It should be possible for a GUI to query the conflict objects for
-possible actions (in textual form) and trigger them.
-
-
-Proposed actions by conflict type:
-==================================
-
-The following paragraphs list all the existing conflict types and summarize:
-- the actions that can be proposed to the user,
-- the cleanups that could remain to be done once the conflict is solved,
-
-In practice, the actions will always contain:
-- leave the user solve the conflict by its own means,
-- mark the conflict as solved without any additional action.
-
-
-Text conflicts:
----------------
-
-5 ways:
-- force THIS (for all conflicted regions)
-- force OTHER (for all conflicted regions)
-- manually solve each conflicted region
-- force THIS (overriding all cleanly merged modifications)
-- force OTHER (overriding all cleanly merged modifications)
-
-resolve:
-- delete .THIS, .OTHER, .BASE if present
-
-Content conflicts:
-------------------
-
-3 ways:
-- bzr mv .THIS <item>,
-- bzr mv .OTHER <item>,
-- manually combine .THIS and .OTHER
-
-resolve:
-- delete .THIS, .OTHER, .BASE if present
-
-
-Duplicate paths
----------------
-
-bzr made a choice
-
-3 ways:
-- bzr mv .moved <item> (refuse bzr choice)
-- bzr rm .moved (accept bzr choice)
-- manually combine <item> and .moved
-
-resolve:
-
-- nothing to do ? If the '.moved' file still exists emit a
- warning ? Delete it ? Put it to the trash ?
-
-
-Unversioned parent
-------------------
-
-bzr made a choice: version the parent
-
-3 ways:
-- bzr rm <children>
-- bzr rm <parent>
-- manually rename <children>
-
-resolve:
-- nothing to do nothing more than the conflicted objects have been created
-
-
-Missing parent
---------------
-
-bzr made a choice: create the missing parent and version it.
-
-3 ways:
-- bzr rm <children>
-- bzr rm <parent>
-- manually rename <children>
-
-resolve:
-- nothing to do, nothing more than the conflicted objects have been created
-
-
-Deleting parent
----------------
-
-bzr made a choice: not delete the parent
-
-3 ways:
-- bzr rm <children>
-- bzr rm <parent>
-- manually solve the issue (may be more than a single children)
-
-resolve:
-- nothing to do
-
-
-Path conflict
--------------
-
-bzr made a choice: use the source's name
-
-3 ways:
-- do nothing (accept bzr choice)
-- bzr mv <item> other-name (refuse bzr choice)
-- manually rename to a different name
-
-resolve:
-- nothing to do
-
-Parent loop
------------
-
-bzr made a choice: keep the existing renaming
-
-3 ways:
-- do nothing (accept bzr choice)
-- bzr mv this_parent/this_children other_parent/other_children
-- manually rename the items
-
-resolve:
-- nothing to do
-
-
-Non-directory parent
---------------------
-
-bzr made a choice: create a <parent>.new directory
-
-There is no obvious single action that can solve the conflict
-here, but let's try anyway.
-
-3 ways:
-- bzr rm <parent>.new
-- bzr rm <parent> + bzr mv <parent>.new <parent>
-- manually rename the items
-
-resolve:
-- nothing to do
=== modified file 'bzrlib/conflicts.py'
--- a/bzrlib/conflicts.py 2009-10-20 14:47:12 +0000
+++ b/bzrlib/conflicts.py 2009-10-27 16:18:30 +0000
@@ -159,7 +159,6 @@
def _resolve_interactive(tree, path):
- import sys # TEMPORARY
tree.lock_tree_write()
try:
tree_conflicts = tree.conflicts()
@@ -171,6 +170,7 @@
# FIXME: we should really do a loop below as some paths may be involved
# in several conflicts but it's not yet clear how we will handle that.
c = selected[0]
+ import sys # TEMPORARY
action_name = sys.stdin.readline()
action_name = action_name.rstrip('\n')
# Crude exit
More information about the bazaar-commits
mailing list