1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
|
# This file is for listing TODOs for branches that are being worked on.
# It should ALWAYS be empty in the mainline or in integration branches.
#
#
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
https://bugs.edge.launchpad.net/bzr/+bug/457793
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 more to do than removing the conflicted objects that
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
|