~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/en/user-guide/conflicts.txt

  • Committer: Blake Winton
  • Date: 2007-10-16 16:02:01 UTC
  • mto: This revision was merged to the branch mainline in revision 2921.
  • Revision ID: bwinton@latte.ca-20071016160201-os2bci2ujf7in7an
Change 'print >> f,'s to 'f.write('s.

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
Conflict Types
2
 
==============
 
1
=================
 
2
Conflict handling
 
3
=================
3
4
 
4
5
Some operations, like merge, revert and pull, modify the contents of your
5
6
working tree.  These modifications are programmatically generated, and so they
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.
 
7
may conflict with the current state of your working tree. Many kinds of changes
 
8
can be combined programmatically, but sometimes only a human can determine the
 
9
right thing to do.  When this happens Bazaar will inform you that there is a
 
10
conflict and then ask you to resolve it.  The command to tell Bazaar a conflict
 
11
is resolved is ``resolve``, but you must perform some action before you can do
 
12
this.
43
13
 
44
14
Each type of conflict is explained below, and the action which must be done to
45
15
resolve the conflict is outlined.
46
16
 
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.
59
17
 
60
18
Text conflicts
61
 
--------------
62
 
 
 
19
==============
63
20
Typical message::
64
21
 
65
22
  Text conflict in FILE
97
54
you are done editing, the file should look like it never had a conflict, and be
98
55
ready to commit.
99
56
 
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.
 
57
When you have resolved text conflicts, just run "bzr resolve", and Bazaar will
 
58
auto-detect which conflicts you have resolved.
106
59
 
107
60
Content conflicts
108
 
-----------------
109
 
 
 
61
=================
110
62
Typical message::
111
63
 
112
64
  Contents conflict in FILE
113
65
 
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.
 
66
This conflict happens when there are conflicting changes in the target tree and
 
67
the merge source, but the conflicted items are not text files.  They may be
 
68
binary files, or symlinks, or directories.  It can even happen with files that
 
69
are deleted on one side, and modified on the other.
118
70
 
119
71
Like text conflicts, Bazaar will emit THIS, OTHER and BASE files.  (They may be
120
72
regular files, symlinks or directories).  But it will not include a "main copy"
121
73
of the file with herringbone conflict markers.  It will appear that the "main
122
74
copy" has been renamed to THIS or OTHER.
123
75
 
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.
137
 
 
138
 
Tag conflicts
139
 
-------------
140
 
 
141
 
Typical message::
142
 
 
143
 
  Conflicting tags:
144
 
      version-0.1
145
 
 
146
 
When pulling from or pushing to another branch, Bazaar informs you about tags
147
 
that conflict between the two branches; that is the same tag points to two
148
 
different revisions.  You need not resolve these conflicts, but subsequent
149
 
uses of pull or push will result in the same message.
150
 
 
151
 
To resolve the conflict, you must apply the correct tags to either the target
152
 
branch or the source branch as appropriate.  Use "bzr tags --show-ids -d
153
 
SOURCE_URL" to see the tags in the source branch.  If you want to make the
154
 
target branch's tags match the source branch, then in the target branch do
155
 
``bzr tag --force -r revid:REVISION_ID CONFLICTING_TAG`` for each of the
156
 
CONFLICTING_TAGs, where REVISION_ID comes from the list of tags in the source
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.)
161
 
 
162
 
Duplicate paths
163
 
---------------
164
 
 
 
76
To resolve this, use "bzr mv" to rename the file back to its normal name, and
 
77
combine the changes manually.  When you are satisfied, run "bzr resolve
 
78
FILE".  Bazaar cannot auto-detect when conflicts of this kind have been
 
79
resolved.
 
80
 
 
81
Duplicate Paths
 
82
===============
165
83
Typical message::
166
84
 
167
85
  Conflict adding file FILE.  Moved existing file to FILE.moved.
168
86
 
169
87
Sometimes Bazaar will attempt to create a file using a pathname that has
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.
184
 
 
185
 
Unversioned parent
186
 
------------------
187
 
 
 
88
already been used.  The existing file will be renamed to "FILE.moved".  If
 
89
you wish, you can rename either one of these files, or combine their contents.
 
90
When you are satisfied, you can run "bzr resolve FILE" to mark the conflict as
 
91
resolved.
 
92
 
 
93
Unversioned Parent
 
94
==================
188
95
Typical message::
189
96
 
190
97
    Conflict because FILE is not versioned, but has versioned children.
197
104
the file or the directory.  When you are satisfied, you can run "bzr resolve
198
105
FILE" to mark the conflict as resolved.
199
106
 
200
 
Missing parent
201
 
--------------
202
 
 
 
107
Missing Parent
 
108
==============
203
109
Typical message::
204
110
 
205
111
  Conflict adding files to FILE.  Created directory.
206
112
 
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.
224
 
 
225
 
Deleting parent
226
 
---------------
227
 
 
 
113
This happens when a file has been deleted in the target, but has new children
 
114
in the source.  This is similar to the "unversioned parent" conflict, except
 
115
that the parent directory does not *exist*, instead of just being unversioned.
 
116
In this situation, Bazaar will create the missing parent.  Resolving this issue
 
117
depends very much on the particular scenario.  You may wish to rename or delete
 
118
either the file or the directory.  When you are satisfied, you can run "bzr
 
119
resolve FILE" to mark the conflict as resolved.
 
120
 
 
121
Deleting Parent
 
122
===============
228
123
Typical message::
229
124
 
230
 
  Conflict: can't delete DIR because it is not empty.  Not deleting.
 
125
  Conflict: can't delete FILE because it is not empty.  Not deleting.
231
126
 
232
127
This is the opposite of "missing parent".  A directory is deleted in the
233
128
source, but has new children in the target.  Bazaar will retain the directory.
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.
247
 
 
248
 
Path conflict
249
 
-------------
250
 
 
 
129
Resolving this issue depends very much on the particular scenario.  You may
 
130
wish to rename or delete either the file or the directory.  When you are
 
131
satisfied, you can run "bzr resolve FILE" to mark the conflict as resolved.
 
132
 
 
133
Path Conflict
 
134
=============
251
135
Typical message::
252
136
 
253
137
  Path conflict: PATH1 / PATH2
254
138
 
255
139
This happens when the source and target have each modified the name or parent
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.
269
 
 
270
 
Parent loop
271
 
-----------
272
 
 
 
140
directory of a file.  Bazaar will use the path elements from the source.  You
 
141
can rename the file, and once you have, run "bzr resolve FILE" to mark the
 
142
conflict as resolved.
 
143
 
 
144
Parent Loop
 
145
===========
273
146
Typical message::
274
147
 
275
148
  Conflict moving FILE into DIRECTORY.  Cancelled move.
279
152
For example::
280
153
 
281
154
  $ bzr init
282
 
  $ bzr mkdir white
283
 
  $ bzr mkdir black
284
 
  $ bzr commit -m "BASE"
285
 
  $ bzr branch . ../other
286
 
  $ bzr mv white black
287
 
  $ bzr commit -m "THIS"
288
 
  $ bzr mv ../other/black ../other/white
289
 
  $ bzr commit ../other -m "OTHER"
290
 
  $ bzr merge ../other
291
 
 
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.
305
 
 
306
 
Non-directory parent
307
 
--------------------
308
 
 
309
 
Typical message::
310
 
 
311
 
  Conflict: foo.new is not a directory, but has files in it.
312
 
  Created directory.
313
 
 
314
 
This happens when one side has added files to a directory, and the other side
315
 
has changed the directory into a file or symlink.  For example::
316
 
 
317
 
  $ bzr init
318
 
  $ bzr mkdir foo
319
 
  $ bzr commit -m "BASE"
320
 
  $ bzr branch . ../other
321
 
  $ rmdir foo
322
 
  $ touch foo
323
 
  $ bzr commit -m "THIS"
324
 
  $ bzr mkdir ../other/foo/bar
325
 
  $ bzr commit ../other -m "OTHER"
326
 
  $ bzr merge ../other
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.
 
155
  $ bzr mkdir a
 
156
  $ bzr mkdir b
 
157
  $ bzr commit -m "BASE"
 
158
  $ bzr branch . ../other
 
159
  $ bzr mv a b
 
160
  $ bzr commit -m "THIS"
 
161
  $ bzr mv ../other/b ../other/a
 
162
  $ bzr commit ../other -m "OTHER"
 
163
  $ bzr merge ../other
 
164
 
 
165
In this situation, Bazaar will cancel the move, and leave "a" in "b".
 
166
You can rename the directories if you like, and once you have, run "bzr resolve
 
167
FILE" to mark the conflict as resolved.
340
168
 
341
169
MalformedTransform
342
 
------------------
343
 
 
 
170
==================
344
171
It is possible (though very rare) for Bazaar to raise a MalformedTransform
345
 
exception.  This means that Bazaar encountered a filesystem conflict that it was
 
172
exception.  This means that Bazaar encounted a filesystem conflict that it was
346
173
unable to resolve.  This usually indicates a bug.  Please let us know if you
347
174
encounter this.  Our bug tracker is at https://launchpad.net/bzr/+bugs