← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to Outline.txt

Moved Outline.txt into BRANCH.TODO.

Show diffs side-by-side

added added

removed removed

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