~bzr/ubuntu/lucid/bzr/beta-ppa

« back to all changes in this revision

Viewing changes to bzrlib/help_topics/en/conflict-types.txt

  • Committer: Martin Pool
  • Date: 2010-08-18 04:26:39 UTC
  • mfrom: (129.1.8 packaging-karmic)
  • Revision ID: mbp@sourcefrog.net-20100818042639-mjoxtngyjwiu05fo
* PPA rebuild for lucid.
* PPA rebuild for karmic.
* PPA rebuild onto jaunty.
* New upstream release.

Show diffs side-by-side

added added

removed removed

Lines of Context:
3
3
 
4
4
Some operations, like merge, revert and pull, modify the contents of your
5
5
working tree.  These modifications are programmatically generated, and so they
6
 
may conflict with the current state of your working tree. Many kinds of changes
7
 
can be combined programmatically, but sometimes only a human can determine the
8
 
right thing to do.  When this happens Bazaar will inform you that there is a
9
 
conflict and then ask you to resolve it.  The command to tell Bazaar a conflict
10
 
is resolved is ``resolve``, but you must perform some action before you can do
11
 
this.
 
6
may conflict with the current state of your working tree. 
 
7
 
 
8
When conflicts are present in your working tree (as shown by ``bzr
 
9
conflicts``), you should resolve them and then inform bzr that the conflicts
 
10
have been resolved.
 
11
 
 
12
Resolving conflicts is sometimes not obvious. Either because the user that
 
13
should resolve them is not the one responsible for their occurrence, as is the
 
14
case when merging other people's work or because some conflicts are presented
 
15
in a way that is not easy to understand.
 
16
 
 
17
Bazaar tries to avoid conflicts ; its aim is to ask you to resolve the
 
18
conflict if and only if there's an actual conceptual conflict in the source
 
19
tree.  Because Bazaar doesn't understand the real meaning of the files being
 
20
versioned, it can, when faced with ambiguities, fall short in either direction
 
21
trying to resolve the conflict itself. Many kinds of changes can be combined
 
22
programmatically, but sometimes only a human can determine the right thing to
 
23
do.
 
24
 
 
25
When Bazaar generates a conflict, it adds information into the working tree to
 
26
present the conflicting versions, and it's up to you to find the correct
 
27
resolution.
 
28
 
 
29
Whatever the conflict is, resolving it is roughly done in two steps::
 
30
 
 
31
- modify the working tree content so that the conflicted item is now in the
 
32
  state you want to keep,
 
33
 
 
34
- inform Bazaar that the conflict is now solved and ask to cleanup any
 
35
  remaining generated information (``bzr resolve <item>``).
 
36
 
 
37
For most conflict types, there are some obvious ways to modify the working
 
38
tree and put it into the desired state. For some types of conflicts, Bazaar
 
39
itself already made a choice, when possible.
 
40
 
 
41
Yet, whether Bazaar makes a choice or not, there are some other simple but
 
42
different ways to resolve the conflict.
12
43
 
13
44
Each type of conflict is explained below, and the action which must be done to
14
45
resolve the conflict is outlined.
15
46
 
 
47
Various actions are available depending on the kind of conflict, for some of
 
48
these actions, Bazaar can provide some help. In the end you should at least
 
49
inform Bazaar that you're done with the conflict with::
 
50
 
 
51
  ``bzr resolve FILE --action=done'
 
52
 
 
53
Note that this is the default action when a single file is involved so you can
 
54
simply use::
 
55
 
 
56
   ``bzr resolve FILE``
 
57
 
 
58
See ``bzr help resolve`` for more details.
16
59
 
17
60
Text conflicts
18
61
--------------
54
97
you are done editing, the file should look like it never had a conflict, and be
55
98
ready to commit.
56
99
 
57
 
When you have resolved text conflicts, just run "bzr resolve", and Bazaar will
58
 
auto-detect which conflicts you have resolved.
 
100
When you have resolved text conflicts, just run ``bzr resolve --auto``, and
 
101
Bazaar will auto-detect which conflicts you have resolved.
 
102
 
 
103
When the conflict is resolved, Bazaar deletes the previously generated
 
104
``.BASE``, ``.THIS`` and ``.OTHER`` files if they are still present in the
 
105
working tree.
59
106
 
60
107
Content conflicts
61
108
-----------------
64
111
 
65
112
  Contents conflict in FILE
66
113
 
67
 
This conflict happens when there are conflicting changes in the target tree and
68
 
the merge source, but the conflicted items are not text files.  They may be
69
 
binary files, or symlinks, or directories.  It can even happen with files that
70
 
are deleted on one side, and modified on the other.
 
114
This conflict happens when there are conflicting changes in the working tree
 
115
and the merge source, but the conflicted items are not text files.  They may
 
116
be binary files, or symlinks, or directories.  It can even happen with files
 
117
that are deleted on one side, and modified on the other.
71
118
 
72
119
Like text conflicts, Bazaar will emit THIS, OTHER and BASE files.  (They may be
73
120
regular files, symlinks or directories).  But it will not include a "main copy"
74
121
of the file with herringbone conflict markers.  It will appear that the "main
75
122
copy" has been renamed to THIS or OTHER.
76
123
 
77
 
To resolve this, use "bzr mv" to rename the file back to its normal name, and
78
 
combine the changes manually.  When you are satisfied, run "bzr resolve
79
 
FILE".  Bazaar cannot auto-detect when conflicts of this kind have been
80
 
resolved.
 
124
To resolve that kind of conflict, you should rebuild FILE from either version
 
125
or a combination of both.
 
126
 
 
127
``bzr resolve`` recognizes the following actions:
 
128
 
 
129
- ``--action=take-this`` will issue ``bzr mv FILE.THIS FILE``,
 
130
- ``--action=take-other`` will issue ``bzr mv FILE.OTHER FILE``,
 
131
- ``--action=done`` will just mark the conflict as resolved.
 
132
 
 
133
Any action will also delete the previously generated ``.BASE``, ``.THIS`` and
 
134
``.OTHER`` files if they are still present in the working tree.
 
135
 
 
136
Bazaar cannot auto-detect when conflicts of this kind have been resolved.
81
137
 
82
138
Tag conflicts
83
139
-------------
95
151
To resolve the conflict, you must apply the correct tags to either the target
96
152
branch or the source branch as appropriate.  Use "bzr tags --show-ids -d
97
153
SOURCE_URL" to see the tags in the source branch.  If you want to make the
98
 
target branch's tags match the source branch, then in the target branch do 
 
154
target branch's tags match the source branch, then in the target branch do
99
155
``bzr tag --force -r revid:REVISION_ID CONFLICTING_TAG`` for each of the
100
156
CONFLICTING_TAGs, where REVISION_ID comes from the list of tags in the source
101
 
branch.  You need not call "bzr resolve" after doing this.  To resolve in favor of the target branch, you need to similarly use ``tag --force`` in the source
102
 
branch.  (Note that pulling or pushing using --overwrite will overwrite all
103
 
tags as well.)
 
157
branch.  You need not call "bzr resolve" after doing this.  To resolve in
 
158
favor of the target branch, you need to similarly use ``tag --force`` in the
 
159
source branch.  (Note that pulling or pushing using --overwrite will overwrite
 
160
all tags as well.)
104
161
 
105
162
Duplicate paths
106
163
---------------
110
167
  Conflict adding file FILE.  Moved existing file to FILE.moved.
111
168
 
112
169
Sometimes Bazaar will attempt to create a file using a pathname that has
113
 
already been used.  The existing file will be renamed to "FILE.moved".  If
114
 
you wish, you can rename either one of these files, or combine their contents.
115
 
When you are satisfied, you can run "bzr resolve FILE" to mark the conflict as
116
 
resolved.
 
170
already been used.  The existing file will be renamed to "FILE.moved".  
 
171
 
 
172
To resolve that kind of conflict, you should rebuild FILE from either version
 
173
or a combination of both.
 
174
 
 
175
``bzr resolve`` recognizes the following actions::
 
176
 
 
177
- ``--action=take-this`` will issue ``bzr rm FILE ; bzr mv FILE.moved FILE``,
 
178
- ``--action=take-other`` will issue ``bzr rm FILE.moved``,
 
179
- ``--action=done`` will just mark the conflict as resolved.
 
180
 
 
181
Note that you must get rid of FILE.moved before using ``--action=done``.
 
182
 
 
183
Bazaar cannot auto-detect when conflicts of this kind have been resolved.
117
184
 
118
185
Unversioned parent
119
186
------------------
137
204
 
138
205
  Conflict adding files to FILE.  Created directory.
139
206
 
140
 
This happens when a file has been deleted in the target, but has new children
141
 
in the source.  This is similar to the "unversioned parent" conflict, except
142
 
that the parent directory does not *exist*, instead of just being unversioned.
143
 
In this situation, Bazaar will create the missing parent.  Resolving this issue
144
 
depends very much on the particular scenario.  You may wish to rename or delete
145
 
either the file or the directory.  When you are satisfied, you can run "bzr
146
 
resolve FILE" to mark the conflict as resolved.
 
207
This happens when a directory has been deleted in the target, but has new
 
208
children in the source.  This is similar to the "unversioned parent" conflict,
 
209
except that the parent directory does not *exist*, instead of just being
 
210
unversioned.  In this situation, Bazaar will create the missing parent.
 
211
Resolving this issue depends very much on the particular scenario.
 
212
 
 
213
To resolve that kind of conflict, you should either remove or rename the
 
214
children or the directory or a combination of both.
 
215
 
 
216
``bzr resolve`` recognizes the following actions::
 
217
 
 
218
- ``--action=take-this`` will issue ``bzr rm directory`` including the children,
 
219
- ``--action=take-other`` will acknowledge Bazaar choice to keep the children
 
220
  and restoring the directory,
 
221
- ``--action=done`` will just mark the conflict as resolved.
 
222
 
 
223
Bazaar cannot auto-detect when conflicts of this kind have been resolved.
147
224
 
148
225
Deleting parent
149
226
---------------
150
227
 
151
228
Typical message::
152
229
 
153
 
  Conflict: can't delete FILE because it is not empty.  Not deleting.
 
230
  Conflict: can't delete DIR because it is not empty.  Not deleting.
154
231
 
155
232
This is the opposite of "missing parent".  A directory is deleted in the
156
233
source, but has new children in the target.  Bazaar will retain the directory.
157
 
Resolving this issue depends very much on the particular scenario.  You may
158
 
wish to rename or delete either the file or the directory.  When you are
159
 
satisfied, you can run "bzr resolve FILE" to mark the conflict as resolved.
 
234
Resolving this issue depends very much on the particular scenario.
 
235
 
 
236
To resolve that kind of conflict, you should either remove or rename the
 
237
children or the directory or a combination of both.
 
238
 
 
239
``bzr resolve`` recognizes the following actions::
 
240
 
 
241
- ``--action=take-this`` will acknowledge Bazaar choice to keep the directory,
 
242
- ``--action=take-other`` will issue ``bzr rm directory`` including the 
 
243
  children,
 
244
- ``--action=done`` will just mark the conflict as resolved.
 
245
 
 
246
Bazaar cannot auto-detect when conflicts of this kind have been resolved.
160
247
 
161
248
Path conflict
162
249
-------------
166
253
  Path conflict: PATH1 / PATH2
167
254
 
168
255
This happens when the source and target have each modified the name or parent
169
 
directory of a file.  Bazaar will use the path elements from the source.  You
170
 
can rename the file, and once you have, run "bzr resolve FILE" to mark the
171
 
conflict as resolved.
 
256
directory of a file.  Bazaar will use the path elements from the source.
 
257
 
 
258
To resolve that kind of conflict, you just have to decide what name should be
 
259
retained for the file involved.
 
260
 
 
261
``bzr resolve`` recognizes the following actions::
 
262
 
 
263
- ``--action=take-this`` will revert Bazaar choice and keep ``PATH1`` by
 
264
  issuing ``bzr mv PATH2 PATH1``,
 
265
- ``--action=take-other`` will acknowledge Bazaar choice of keeping ``PATH2``,
 
266
- ``--action=done`` will just mark the conflict as resolved.
 
267
 
 
268
Bazaar cannot auto-detect when conflicts of this kind have been resolved.
172
269
 
173
270
Parent loop
174
271
-----------
182
279
For example::
183
280
 
184
281
  $ bzr init
185
 
  $ bzr mkdir a
186
 
  $ bzr mkdir b
 
282
  $ bzr mkdir white
 
283
  $ bzr mkdir black
187
284
  $ bzr commit -m "BASE"
188
285
  $ bzr branch . ../other
189
 
  $ bzr mv a b
 
286
  $ bzr mv white black
190
287
  $ bzr commit -m "THIS"
191
 
  $ bzr mv ../other/b ../other/a
 
288
  $ bzr mv ../other/black ../other/white
192
289
  $ bzr commit ../other -m "OTHER"
193
290
  $ bzr merge ../other
194
291
 
195
 
In this situation, Bazaar will cancel the move, and leave "a" in "b".
196
 
You can rename the directories if you like, and once you have, run "bzr resolve
197
 
FILE" to mark the conflict as resolved.
 
292
In this situation, Bazaar will cancel the move, and leave ``white`` in
 
293
``black``.  To resolve that kind of conflict, you just have to decide what
 
294
name should be retained for the directories involved.
 
295
 
 
296
``bzr resolve`` recognizes the following actions::
 
297
 
 
298
- ``--action=take-this`` will acknowledge Bazaar choice of leaving ``white`` 
 
299
  in ``black``,
 
300
- ``--action=take-other`` will revert Bazaar choice and move ``black`` in
 
301
  ``white`` by issuing ``bzr mv black/white white ; bzr mv black white``,
 
302
- ``--action=done`` will just mark the conflict as resolved.
 
303
 
 
304
Bazaar cannot auto-detect when conflicts of this kind have been resolved.
198
305
 
199
306
Non-directory parent
200
307
--------------------
201
308
 
202
309
Typical message::
203
310
 
204
 
  Conflict: FILE.new is not a directory, but has files in it.
 
311
  Conflict: foo.new is not a directory, but has files in it.
205
312
  Created directory.
206
313
 
207
314
This happens when one side has added files to a directory, and the other side
208
315
has changed the directory into a file or symlink.  For example::
209
316
 
210
317
  $ bzr init
211
 
  $ bzr mkdir a
 
318
  $ bzr mkdir foo
212
319
  $ bzr commit -m "BASE"
213
320
  $ bzr branch . ../other
214
 
  $ rmdir a
215
 
  $ touch a
 
321
  $ rmdir foo
 
322
  $ touch foo
216
323
  $ bzr commit -m "THIS"
217
 
  $ bzr mkdir ../other/a/b
 
324
  $ bzr mkdir ../other/foo/bar
218
325
  $ bzr commit ../other -m "OTHER"
219
326
  $ bzr merge ../other
220
327
 
 
328
To resolve that kind of conflict, you have to decide what name should be
 
329
retained for the file, directory or symlink involved.
 
330
 
 
331
``bzr resolve`` recognizes the following actions::
 
332
 
 
333
- ``--action=take-this`` will issue ``bzr rm --force foo.new`` and 
 
334
  ``bzr add foo``,
 
335
- ``--action=take-other`` will issue ``bzr rm --force foo`` and 
 
336
  ``bzr mv foo.new foo``,
 
337
- ``--action=done`` will just mark the conflict as resolved.
 
338
 
 
339
Bazaar cannot auto-detect when conflicts of this kind have been resolved.
221
340
 
222
341
MalformedTransform
223
342
------------------