p4 resolve
Synopsis
Resolve conflicts between file revisions.
Syntax
p4 [g-opts
] resolve [-aoptions
] [-Aoptions
] [-doptions
] [-f -n -N -o -t -v]
[-c change
] [file
...]
Description
Use p4 resolve
to combine the contents of two files or file
revisions into a single file revision in your workspace. Two situations
require the use of p4 resolve
before a file can be submitted:
-
When a simple conflict exists: the revision of a file last synced to the client workspace is not the head revision at the time of the submit.
For example, Alice does a
p4 sync
followed by ap4 edit
of filefile.c
, and Bob does the same thing. Alicep4 submit
sfile.c
, and then Bob tries to submitfile.c
. Bob’s submit fails because if his version offile.c
were to be accepted into the depot, Alice’s changes tofile.c
would no longer be visible. Bob must resolve the conflict before he can submit the file. - When
p4 integrate
has been used to schedule the integration of changes from one file (or branch) to another.
The primary difference between these two cases is that resolving a simple file conflict involves multiple revisions of a single file, but resolving for integration involves combining two separate files. In either case:
- If the file is of type
text
,p4 resolve
allows the user to use the file in the client workspace instead of the file in the depot, overwrite the file in the client workspace with the file in the depot, or merge changes from both the depot revision and the client workspace revision into a single file. - If the file is of type
binary
, only the first two options (use the file in the workspace, or overwrite the file in the workspace with the file in the depot) are normally available, because merges generally do not work with binary files.
The output of p4 resolve
is primarily diagnostic in nature;
files are either resolved against ("vs") another file, copied, merged,
edited, branched, added, deleted, moved, or ignored with respect to
other files. The actual work performed by p4 resolve
is
reflected by the changes it makes to files in the client workspace.
Revisions Used to Detect Conflicts
The p4 resolve
dialog refers to four file revisions whose
meaning depends on whether or not the resolution fixes a simple file
conflict or is resolving for integration:
Term | Meaning when Resolving Conflicts | Meaning when Resolving for Integration |
---|---|---|
yours |
The revision of the file in the client workspace |
The file to which changes are being propagated (in integration terminology, this is the target file). Changes are made to the version of this file in the client workspace, and this file is later submitted to the depot. |
theirs |
The head revision of the file in the depot. |
The file revision in the depot from which changes are being propagated (in integration terminology, this is the source file). This file is not changed in the depot or the client workspace. |
base |
The file revision synced to the client workspace before it was opened for edit. |
The previously-integrated revision of theirs. The latest common ancestor of both yours and theirs. |
merge |
A file version generated by Perforce from yours, theirs, and base. The user can edit this revision during the resolve process if the file is a text file. |
Same as the meaning at left. |
Resolve Options and Details
The interactive p4 resolve
dialog presents the following
options. Note that the dialog options are not the same as the command
line options.
Dialog Option | Short Meaning | What it Does | Available by Default for Binary Files? |
---|---|---|---|
|
edit merged |
Edit the preliminary merge file generated by Perforce. |
no |
|
edit yours |
Edit the revision of the file currently in the workspace. |
yes |
|
edit theirs |
Edit the revision in the depot with which the workspace revision conflicts (usually the head revision). This edit is read-only. |
yes |
|
diff yours |
Show diffs between yours and base. |
no |
|
diff theirs |
Show diffs between theirs and base. |
no |
|
diff merge |
Show diffs between merge and base. |
no |
|
diff |
Show diffs between merge and yours. |
yes |
|
merge |
Invoke the command:
To use this option, you must set the environment variable
|
no |
|
help |
Display help for |
yes |
|
skip |
Don’t perform the resolve right now. |
yes |
|
accept yours |
Accept yours, ignoring changes that may have been made in theirs. |
yes |
|
accept theirs |
Accept theirs into the client workspace as the resolved revision. The revision (yours) that was in the client workspace is overwritten. When resolving simple conflicts, this option is identical to performing
|
yes |
|
accept merge |
Accept the merged file into the client workspace as the resolved revision without any modification. The revision (yours) originally in the client workspace is overwritten. |
no |
|
accept edit |
If you edited the file (that is, by selecting “e” from the |
no |
|
accept |
Keep Perforce’s recommended result:
|
no |
Resolution of a file is completed when any of the accept
dialog
options are chosen. To resolve the file later or to revert the change,
skip
the file.
To help decide which option to choose, counts of four types of changes
that have been made to the file revisions are displayed by p4
resolve
:
Diff Chunks: 2 yours + 3 theirs + 5 both + 7 conflicting
The meanings of these values are:
Count | Meaning |
---|---|
|
|
|
|
|
|
|
|
If there are no conflicting chunks, it is often safe to accept Perforce’s generated merge file, because Perforce will substitute all the changes from yours and theirs into base.
If there are conflicting chunks, the merge file must be edited. In this case, Perforce will include the conflicting yours, theirs, and base text in the merge file; it’s up to you to choose which version of the chunk you want to keep.
The different text is clearly delineated with file markers:
>>>> ORIGINAL VERSION file #n <text>==== THEIR VERSION file #m <text>==== YOUR VERSION file <text><<<<
Choose the text you want to keep; delete the conflicting chunks and all the difference markers.
Options
|
Skip the resolution dialog, and resolve the files automatically as follows:
|
|
Action (non-content) resolves: Constrain the type of resolve to branching, deletion, file type change, or move/rename.
For details, see the Helix Versioning Engine User Guide and Non-Content-Related Resolves. |
|
When merging files, ignore specified differences in whitespace or
line-ending convention. (If you use these options, and the files
differ by whitespace only,
|
|
Allow already resolved, but not yet submitted, files to be resolved again. |
|
List the files that need resolving without actually performing the resolve. |
|
Preview the operation with additional information about any non-content resolve actions that are scheduled. |
|
Output the base file name and revision to be used during the resolve. |
|
Force a three-way merge, even on binary (non-text) files. This allows
you to inspect diffs between files of any type, and lets you merge
non-text files if |
|
Include conflict markers in the file for all changes between yours and base, and between theirs and base. Normally, conflict markers are included only when yours and theirs conflict. |
|
Limit the scope of the resolve operation to the files opened in the specified changelist number. |
|
See “Global Options”. |
Usage Notes
Can File Arguments Use Revision Specifier? | Can File Arguments Use Revision Range? | Minimal Access Level Required |
---|---|---|
No |
No |
|
-
p4 resolve
works only with files that have been scheduled for resolve. Three operations schedule files for resolution:-
Integrating the file with
p4 integrate
orp4 merge
.When scheduling files for resolve,
p4 integrate
selects the closest common ancestor as the base. Thep4 merge
command selects the revision with the most edits in common with the source and target.
-
- Submitting an open file that was synced from a revision other then the current head revision; the submit fails, and the file is scheduled for resolve.
-
Running
p4 sync
instead of runningp4 submit
on the open file. Nothing is copied into the client workspace; instead, the file is scheduled for resolve. (The only benefit of scheduling files for resolve withp4 sync
instead of a failed submit is that the submit will not fail).When
p4 resolve
is run with no file arguments, it operates on all files in the client workspace that have been scheduled for resolve. - If translation errors occur during integrations between
text
andunicode
files, the most likely cause is the presence of non-ASCII characters in thetext
file. Either remove the non-ASCII characters from the file before integration, or setP4CHARSET
toutf8
and attempt the merge again.