~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to bzrlib/help_topics/en/conflicts.txt

Modify test_tsort_partial to accept multiple valid orderings.

This test previously checked for an exact match on the result of
tsort.topo_sort, while only a partial ordering is garantueed.  The current
implementation of topo_sort indeed returns the graph in lexicographical order,
but this depends on the order in which dict.popitem() pops and that is a
Python implementation detail not to be relied on.

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
Conflict Types
2
 
==============
 
1
Conflicts Types
 
2
===============
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. 
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
 
1. Modify the working tree content so that the conflicted item is now in the
32
 
   state you want to keep, then
33
 
 
34
 
2. 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.
 
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.
43
12
 
44
13
Each type of conflict is explained below, and the action which must be done to
45
14
resolve the conflict is outlined.
46
15
 
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
16
 
60
17
Text conflicts
61
18
--------------
87
44
 
88
45
The correct resolution would be "Martin Pool released Bazaar."
89
46
 
90
 
You can handle text conflicts either by editing the main copy of the file,
91
 
or by invoking external tools on the THIS, OTHER and BASE versions.  It's
92
 
worth mentioning that resolving text conflicts rarely involves picking one
93
 
set of changes over the other (but see below when you encounter these
94
 
cases).  More often, the two sets of changes must be intelligently combined.
 
47
You can handle text conflicts either by editing the main copy of the file, or
 
48
by invoking external tools on the THIS, OTHER and BASE versions.  It's worth
 
49
mentioning that resolving text conflicts rarely involves picking one set of
 
50
changes over the other.  More often, the two sets of changes must be
 
51
intelligently combined.
95
52
 
96
53
If you edit the main copy, be sure to remove the herringbone markers.  When
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.
106
 
 
107
 
 
108
 
When you want to pick one set of changes over the other, you can use ``bzr
109
 
resolve`` with one of the following actions:
110
 
 
111
 
* ``--action=take-this`` will issue ``mv FILE.THIS FILE``,
112
 
* ``--action=take-other`` will issue ``mv FILE.OTHER FILE``.
113
 
 
114
 
Note that if you have modified ``FILE.THIS`` or ``FILE.OTHER``, these
115
 
modifications will be taken into account.
 
57
When you have resolved text conflicts, just run "bzr resolve", and Bazaar will
 
58
auto-detect which conflicts you have resolved.
116
59
 
117
60
Content conflicts
118
61
-----------------
121
64
 
122
65
  Contents conflict in FILE
123
66
 
124
 
This conflict happens when there are conflicting changes in the working tree
125
 
and the merge source, but the conflicted items are not text files.  They may
126
 
be binary files, or symlinks, or directories.  It can even happen with files
127
 
that are deleted on one side, and modified on the other.
 
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.
128
71
 
129
72
Like text conflicts, Bazaar will emit THIS, OTHER and BASE files.  (They may be
130
73
regular files, symlinks or directories).  But it will not include a "main copy"
131
74
of the file with herringbone conflict markers.  It will appear that the "main
132
75
copy" has been renamed to THIS or OTHER.
133
76
 
134
 
To resolve that kind of conflict, you should rebuild FILE from either version
135
 
or a combination of both.
136
 
 
137
 
``bzr resolve`` recognizes the following actions:
138
 
 
139
 
* ``--action=take-this`` will issue ``bzr mv FILE.THIS FILE``,
140
 
* ``--action=take-other`` will issue ``bzr mv FILE.OTHER FILE``,
141
 
* ``--action=done`` will just mark the conflict as resolved.
142
 
 
143
 
Any action will also delete the previously generated ``.BASE``, ``.THIS`` and
144
 
``.OTHER`` files if they are still present in the working tree.
145
 
 
146
 
Bazaar cannot auto-detect when conflicts of this kind have been resolved.
147
 
 
148
 
Tag conflicts
149
 
-------------
150
 
 
151
 
Typical message::
152
 
 
153
 
  Conflicting tags:
154
 
      version-0.1
155
 
 
156
 
When pulling from or pushing to another branch, Bazaar informs you about tags
157
 
that conflict between the two branches; that is the same tag points to two
158
 
different revisions.  You need not resolve these conflicts, but subsequent
159
 
uses of pull or push will result in the same message.
160
 
 
161
 
To resolve the conflict, you must apply the correct tags to either the target
162
 
branch or the source branch as appropriate.  Use "bzr tags --show-ids -d
163
 
SOURCE_URL" to see the tags in the source branch.  If you want to make the
164
 
target branch's tags match the source branch, then in the target branch do
165
 
``bzr tag --force -r revid:REVISION_ID CONFLICTING_TAG`` for each of the
166
 
CONFLICTING_TAGs, where REVISION_ID comes from the list of tags in the source
167
 
branch.  You need not call "bzr resolve" after doing this.  To resolve in
168
 
favor of the target branch, you need to similarly use ``tag --force`` in the
169
 
source branch.  (Note that pulling or pushing using --overwrite will overwrite
170
 
all tags as well.)
 
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.
171
81
 
172
82
Duplicate paths
173
83
---------------
177
87
  Conflict adding file FILE.  Moved existing file to FILE.moved.
178
88
 
179
89
Sometimes Bazaar will attempt to create a file using a pathname that has
180
 
already been used.  The existing file will be renamed to "FILE.moved".  
181
 
 
182
 
To resolve that kind of conflict, you should rebuild FILE from either version
183
 
or a combination of both.
184
 
 
185
 
``bzr resolve`` recognizes the following actions:
186
 
 
187
 
* ``--action=take-this`` will issue ``bzr rm FILE ; bzr mv FILE.moved FILE``,
188
 
* ``--action=take-other`` will issue ``bzr rm FILE.moved``,
189
 
* ``--action=done`` will just mark the conflict as resolved.
190
 
 
191
 
Note that you must get rid of FILE.moved before using ``--action=done``.
192
 
 
193
 
Bazaar cannot auto-detect when conflicts of this kind have been resolved.
 
90
already been used.  The existing file will be renamed to "FILE.moved".  If
 
91
you wish, you can rename either one of these files, or combine their contents.
 
92
When you are satisfied, you can run "bzr resolve FILE" to mark the conflict as
 
93
resolved.
194
94
 
195
95
Unversioned parent
196
96
------------------
214
114
 
215
115
  Conflict adding files to FILE.  Created directory.
216
116
 
217
 
This happens when a directory has been deleted in the target, but has new
218
 
children in the source.  This is similar to the "unversioned parent" conflict,
219
 
except that the parent directory does not *exist*, instead of just being
220
 
unversioned.  In this situation, Bazaar will create the missing parent.
221
 
Resolving this issue depends very much on the particular scenario.
222
 
 
223
 
To resolve that kind of conflict, you should either remove or rename the
224
 
children or the directory or a combination of both.
225
 
 
226
 
``bzr resolve`` recognizes the following actions:
227
 
 
228
 
* ``--action=take-this`` will issue ``bzr rm directory`` including the
229
 
  children,
230
 
* ``--action=take-other`` will acknowledge Bazaar choice to keep the children
231
 
  and restoring the directory,
232
 
* ``--action=done`` will just mark the conflict as resolved.
233
 
 
234
 
Bazaar cannot auto-detect when conflicts of this kind have been resolved.
 
117
This happens when a file has been deleted in the target, but has new children
 
118
in the source.  This is similar to the "unversioned parent" conflict, except
 
119
that the parent directory does not *exist*, instead of just being unversioned.
 
120
In this situation, Bazaar will create the missing parent.  Resolving this issue
 
121
depends very much on the particular scenario.  You may wish to rename or delete
 
122
either the file or the directory.  When you are satisfied, you can run "bzr
 
123
resolve FILE" to mark the conflict as resolved.
235
124
 
236
125
Deleting parent
237
126
---------------
238
127
 
239
128
Typical message::
240
129
 
241
 
  Conflict: can't delete DIR because it is not empty.  Not deleting.
 
130
  Conflict: can't delete FILE because it is not empty.  Not deleting.
242
131
 
243
132
This is the opposite of "missing parent".  A directory is deleted in the
244
 
source, but has new children in the target (either because a directory
245
 
deletion is merged or because the merge introduce new children).  Bazaar
246
 
will retain the directory.  Resolving this issue depends very much on the
247
 
particular scenario.
248
 
 
249
 
To resolve that kind of conflict, you should either remove or rename the
250
 
children or the directory or a combination of both.
251
 
 
252
 
``bzr resolve`` recognizes the following actions:
253
 
 
254
 
* ``--action=take-this`` will acknowledge Bazaar choice to keep the directory,
255
 
 
256
 
* ``--action=take-other`` will issue ``bzr rm directory`` including the 
257
 
  children,
258
 
 
259
 
* ``--action=done`` will just mark the conflict as resolved.
260
 
 
261
 
Note that when merging a directory deletion, if unversioned files are
262
 
present, they become potential orphans has they don't have a directory
263
 
parent anymore.
264
 
 
265
 
Handling such orphans, *before* the conflict is created, is controlled by
266
 
setting the ``bzr.transform.orphan_policy`` configuration option.
267
 
 
268
 
There are two possible values for this option:
269
 
 
270
 
* ``conflict`` (the default): will leave the orphans in place and
271
 
  generate a conflicts,
272
 
 
273
 
* ``move``: will move the orphans to a ``bzr-orphans`` directory at the root
274
 
  of the working tree with names like ``<file>.~#~``.
275
 
 
276
 
Bazaar cannot auto-detect when conflicts of this kind have been resolved.
 
133
source, but has new children in the target.  Bazaar will retain the directory.
 
134
Resolving this issue depends very much on the particular scenario.  You may
 
135
wish to rename or delete either the file or the directory.  When you are
 
136
satisfied, you can run "bzr resolve FILE" to mark the conflict as resolved.
277
137
 
278
138
Path conflict
279
139
-------------
283
143
  Path conflict: PATH1 / PATH2
284
144
 
285
145
This happens when the source and target have each modified the name or parent
286
 
directory of a file.  Bazaar will use the path elements from the source.
287
 
 
288
 
To resolve that kind of conflict, you just have to decide what name should be
289
 
retained for the file involved.
290
 
 
291
 
``bzr resolve`` recognizes the following actions:
292
 
 
293
 
* ``--action=take-this`` will revert Bazaar choice and keep ``PATH1`` by
294
 
  issuing ``bzr mv PATH2 PATH1``,
295
 
* ``--action=take-other`` will acknowledge Bazaar choice of keeping ``PATH2``,
296
 
* ``--action=done`` will just mark the conflict as resolved.
297
 
 
298
 
Bazaar cannot auto-detect when conflicts of this kind have been resolved.
 
146
directory of a file.  Bazaar will use the path elements from the source.  You
 
147
can rename the file, and once you have, run "bzr resolve FILE" to mark the
 
148
conflict as resolved.
299
149
 
300
150
Parent loop
301
151
-----------
309
159
For example::
310
160
 
311
161
  $ bzr init
312
 
  $ bzr mkdir white
313
 
  $ bzr mkdir black
 
162
  $ bzr mkdir a
 
163
  $ bzr mkdir b
314
164
  $ bzr commit -m "BASE"
315
165
  $ bzr branch . ../other
316
 
  $ bzr mv white black
 
166
  $ bzr mv a b
317
167
  $ bzr commit -m "THIS"
318
 
  $ bzr mv ../other/black ../other/white
 
168
  $ bzr mv ../other/b ../other/a
319
169
  $ bzr commit ../other -m "OTHER"
320
170
  $ bzr merge ../other
321
171
 
322
 
In this situation, Bazaar will cancel the move, and leave ``white`` in
323
 
``black``.  To resolve that kind of conflict, you just have to decide what
324
 
name should be retained for the directories involved.
325
 
 
326
 
``bzr resolve`` recognizes the following actions:
327
 
 
328
 
* ``--action=take-this`` will acknowledge Bazaar choice of leaving ``white`` 
329
 
  in ``black``,
330
 
* ``--action=take-other`` will revert Bazaar choice and move ``black`` in
331
 
   ``white`` by issuing ``bzr mv black/white white ; bzr mv black white``,
332
 
* ``--action=done`` will just mark the conflict as resolved.
333
 
 
334
 
Bazaar cannot auto-detect when conflicts of this kind have been resolved.
 
172
In this situation, Bazaar will cancel the move, and leave "a" in "b".
 
173
You can rename the directories if you like, and once you have, run "bzr resolve
 
174
FILE" to mark the conflict as resolved.
335
175
 
336
176
Non-directory parent
337
177
--------------------
338
178
 
339
179
Typical message::
340
180
 
341
 
  Conflict: foo.new is not a directory, but has files in it.
 
181
  Conflict: FILE.new is not a directory, but has files in it.
342
182
  Created directory.
343
183
 
344
 
This happens when one side has added files to a directory, and the other side
 
184
This happens when one side has added files to a directory, and the othe side
345
185
has changed the directory into a file or symlink.  For example::
346
186
 
347
187
  $ bzr init
348
 
  $ bzr mkdir foo
 
188
  $ bzr mkdir a
349
189
  $ bzr commit -m "BASE"
350
190
  $ bzr branch . ../other
351
 
  $ rmdir foo
352
 
  $ touch foo
 
191
  $ rmdir a
 
192
  $ touch a
353
193
  $ bzr commit -m "THIS"
354
 
  $ bzr mkdir ../other/foo/bar
 
194
  $ bzr mkdir ../other/a/b
355
195
  $ bzr commit ../other -m "OTHER"
356
196
  $ bzr merge ../other
357
197
 
358
 
To resolve that kind of conflict, you have to decide what name should be
359
 
retained for the file, directory or symlink involved.
360
 
 
361
 
``bzr resolve`` recognizes the following actions:
362
 
 
363
 
* ``--action=take-this`` will issue ``bzr rm --force foo.new`` and 
364
 
  ``bzr add foo``,
365
 
* ``--action=take-other`` will issue ``bzr rm --force foo`` and 
366
 
  ``bzr mv foo.new foo``,
367
 
* ``--action=done`` will just mark the conflict as resolved.
368
 
 
369
 
Bazaar cannot auto-detect when conflicts of this kind have been resolved.
370
198
 
371
199
MalformedTransform
372
200
------------------