← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to BRANCH.TODO

Moved Outline.txt into BRANCH.TODO.

Show diffs side-by-side

added added

removed removed

Lines of Context:
BRANCH.TODO
3
3
# 
4
4
#
5
5
 
 
6
Related Bugs:
 
7
=============
 
8
 
 
9
https://bugs.edge.launchpad.net/bzr/+bug/414589
 
10
 
 
11
https://bugs.edge.launchpad.net/bzr/+bug/236724
 
12
https://bugs.edge.launchpad.net/bzr/+bug/228506
 
13
https://bugs.edge.launchpad.net/bzr/+bug/113809
 
14
https://bugs.edge.launchpad.net/bzr/+bug/322767
 
15
https://bugs.edge.launchpad.net/bzr/+bug/416903
 
16
https://bugs.edge.launchpad.net/bzr/+bug/355964
 
17
 
 
18
https://bugs.edge.launchpad.net/bzr/+bug/257297
 
19
https://bugs.edge.launchpad.net/bzr/+bug/232512
 
20
 
 
21
https://bugs.edge.launchpad.net/bzr/+bug/405264
 
22
 
 
23
 
 
24
TODO:
 
25
=====
 
26
 
 
27
- add more info to Conflict objects:
 
28
  - base revid for text conflict
 
29
  - this requires a format bump ?
 
30
 
 
31
- tests with '.diverted' files ?
 
32
 
 
33
- doc/es/user-guide/resolving_conflicts.txt is really
 
34
  user-reference/resolving_conflicts.txt
 
35
 
 
36
 
 
37
Overall presentation:
 
38
=====================
 
39
 
 
40
When conflicts are present in a working tree (as shown by ``bzr
 
41
conflicts``), the user should resolve them and then inform bzr
 
42
that the conflicts has been resolved.
 
43
 
 
44
Resolving conflicts is sometimes not obvious. Either because the
 
45
user that should resolve them is not the one responsible for
 
46
their occurrence, as is the case when merging other people work
 
47
or because some conflicts are presented in a way that is not easy
 
48
to understand.
 
49
 
 
50
``bzr`` try to avoid conflicts, its aim is to ask the user to
 
51
resolve the conflict if and only if there's an actual conceptual
 
52
conflict in the source tree.  Because bzr doesn't understand the
 
53
real meaning of the files being versioned it can fall short in
 
54
either direction trying to resolve the conflict itself when faced
 
55
with ambiguities.
 
56
 
 
57
When it can't resolve, bzr add information into the working tree
 
58
to present the conflicting versions and leave the resolution to
 
59
the user.
 
60
 
 
61
Whatever the conflict is, resolving it is roughly done in two steps:
 
62
 
 
63
- modify the working tree content so that the conflicted item is
 
64
  now in the desired state, there are,
 
65
 
 
66
- inform bzr that the conflict is now solved and ask to cleanup
 
67
  any remaining generated information (``bzr resolve <item>``).
 
68
 
 
69
 
 
70
For most conflict types, there are some obvious ways to modify
 
71
the working tree and put it into the desired state. For some type
 
72
of conflicts, bzr itself already made a choice when possible.
 
73
 
 
74
Yet, whether bzr made a choice or not, there are some other ways
 
75
simple but alternative ways to resolve the conflict.
 
76
 
 
77
Providing the ``--interactive`` option to ``bzr resolve`` will
 
78
display a short explanation of the conflict and propose some
 
79
actions before marking the file as resolved.
 
80
 
 
81
 
 
82
Design:
 
83
=======
 
84
 
 
85
The Conflict classes will receive additional methods to resolve
 
86
the conflict in alternative ways.
 
87
 
 
88
Resolve will receive a ``--interactive`` option and present a
 
89
list of possible actions (including do nothing) to the user
 
90
before marking the file as resolved.
 
91
 
 
92
The --all and file* parameters will still be honored so that the
 
93
user solve conflicts at his own pace.
 
94
 
 
95
It should be possible for a GUI to query the conflict objects for
 
96
possible actions (in textual form) and trigger them.
 
97
 
 
98
 
 
99
Proposed actions by conflict type:
 
100
==================================
 
101
 
 
102
The following paragraphs list all the existing conflict types and summarize:
 
103
- the actions that can be proposed to the user,
 
104
- the cleanups that could remain to be done once the conflict is solved,
 
105
 
 
106
In practice, the actions will always contain:
 
107
- leave the user solve the conflict by its own means,
 
108
- mark the conflict as solved without any additional action.
 
109
 
 
110
 
 
111
Text conflicts:
 
112
---------------
 
113
 
 
114
5 ways:
 
115
- force THIS (for all conflicted regions)
 
116
- force OTHER (for all conflicted regions)
 
117
- manually solve each conflicted region
 
118
- force THIS (overriding all cleanly merged modifications)
 
119
- force OTHER (overriding all cleanly merged modifications)
 
120
 
 
121
resolve:
 
122
- delete .THIS, .OTHER, .BASE  if present
 
123
 
 
124
Content conflicts:
 
125
------------------
 
126
 
 
127
3 ways:
 
128
- bzr mv .THIS <item>,
 
129
- bzr mv .OTHER <item>,
 
130
- manually combine .THIS and .OTHER
 
131
 
 
132
resolve:
 
133
- delete .THIS, .OTHER, .BASE if present
 
134
 
 
135
 
 
136
Duplicate paths
 
137
---------------
 
138
 
 
139
bzr made a choice
 
140
 
 
141
3 ways:
 
142
- bzr mv .moved <item> (refuse bzr choice)
 
143
- bzr rm .moved (accept bzr choice)
 
144
- manually combine <item> and .moved
 
145
 
 
146
resolve:
 
147
 
 
148
- nothing to do ? If the '.moved' file still exists emit a
 
149
  warning ? Delete it ? Put it to the trash ?
 
150
 
 
151
 
 
152
Unversioned parent
 
153
------------------
 
154
 
 
155
bzr made a choice: version the parent
 
156
 
 
157
3 ways:
 
158
- bzr rm <children>
 
159
- bzr rm <parent>
 
160
- manually rename <children>
 
161
 
 
162
resolve:
 
163
- nothing to do nothing more than the conflicted objects have been created
 
164
 
 
165
 
 
166
Missing parent
 
167
--------------
 
168
 
 
169
bzr made a choice: create the missing parent and version it.
 
170
 
 
171
3 ways:
 
172
- bzr rm <children>
 
173
- bzr rm <parent>
 
174
- manually rename <children>
 
175
 
 
176
resolve:
 
177
- nothing to do, nothing more than the conflicted objects have been created
 
178
 
 
179
 
 
180
Deleting parent
 
181
---------------
 
182
 
 
183
bzr made a choice: not delete the parent
 
184
 
 
185
3 ways:
 
186
- bzr rm <children>
 
187
- bzr rm <parent>
 
188
- manually solve the issue (may be more than a single children)
 
189
 
 
190
resolve:
 
191
- nothing to do
 
192
 
 
193
 
 
194
Path conflict
 
195
-------------
 
196
 
 
197
bzr made a choice: use the source's name
 
198
 
 
199
3 ways:
 
200
- do nothing (accept bzr choice)
 
201
- bzr mv <item> other-name (refuse bzr choice)
 
202
- manually rename to a different name
 
203
 
 
204
resolve:
 
205
- nothing to do 
 
206
 
 
207
Parent loop
 
208
-----------
 
209
 
 
210
bzr made a choice: keep the existing renaming
 
211
 
 
212
3 ways:
 
213
- do nothing (accept bzr choice)
 
214
- bzr mv this_parent/this_children other_parent/other_children
 
215
- manually rename the items
 
216
 
 
217
resolve:
 
218
- nothing to do
 
219
 
 
220
 
 
221
Non-directory parent
 
222
--------------------
 
223
 
 
224
bzr made a choice: create a <parent>.new directory
 
225
 
 
226
There is no obvious single action that can solve the conflict
 
227
here, but let's try anyway.
 
228
 
 
229
3 ways:
 
230
- bzr rm <parent>.new
 
231
- bzr rm <parent> + bzr mv <parent>.new <parent>
 
232
- manually rename the items
 
233
 
 
234
resolve:
 
235
- nothing to do