|
Synopsis
Resolve conflicts between file revisions
Syntax
p4 [g-opts] resolve [-af -am -as -at -ay -f -n -t -v] [file ...]
Description
p4 resolve is used to combine the contents of two files or file revisions into a single file revision. 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 a p4 edit of file foo, Bob does the same thing, Alice p4 submits foo, and then Bob tries to submit foo. Bob's submit will fail because if his foo is accepted into the depot, Alice's changes to foo will no longer be visible.
- When p4 integrate has been used to schedule the integration of changes from one file 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 choose whether to overwrite the file revision in the depot with the file in the client workspace, 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 are normally available, since merges don't generally work with binary files.
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.
|
The p4 resolve dialog presents the following options:
Option
|
Short Meaning
|
What it Does
|
Available by Default for Binary Files?
|
|---|
|
e
|
edit merged
|
Edit the preliminary merge file generated by Perforce
|
no
|
|
ey
|
edit yours
|
Edit the revision of the file currently in the client
|
yes
|
|
et
|
edit theirs
|
Edit the revision in the depot that the client revision conflicts with (usually the head revision). This edit is read-only.
|
yes
|
|
dy
|
diff yours
|
Show diffs between yours and base
|
no
|
|
dt
|
diff theirs
|
Show diffs between theirs and base
|
no
|
|
dm
|
diff merge
|
Show diffs between merge and base
|
no
|
|
d
|
diff
|
Show diffs between merge and yours
|
yes
|
|
m
|
merge
|
Invoke the command
- P4MERGE base theirs yours merge
To use this option, you must set the environment variable P4MERGE to the name of a third-party program that merges the first three files and writes the fourth as a result. This command has no effect if P4MERGE is not set.
|
no
|
|
?
|
help
|
Display help for p4 resolve
|
yes
|
|
s
|
skip
|
Don't perform the resolve right now.
|
yes
|
|
ay
|
accept yours
|
Accept yours , ignoring changes that may have been made in theirs.
|
yes
|
|
at
|
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 p4 revert on the client workspace file. When resolving for integrate, this copies the source file to the target file.
|
yes
|
|
am
|
accept merge
|
Accept merged into the client workspace as the resolved revision. The revision (yours) originally in the client workspace is overwritten.
|
no
|
|
a
|
accept
|
Keep Perforce's recommended result:
- if theirs is identical to base, accept yours;
- if yours is identical to base, accept theirs;
- if yours and theirs are different from base, and there are no conflicts between yours and theirs; accept merge;
- otherwise, there are conflicts between yours and theirs, so skip this file
|
no
|
Resolution of a file is completed when any of the accept options are chosen, or if the file is skipped.
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
|
|---|
|
n yours
|
n segments of yours are different than base.
|
|
n theirs
|
n segments of theirs are different than base.
|
|
n base
|
n segments of theirs and yours are different from base, but are identical to each other.
|
|
n conflicting
|
n segments of theirs and yours are different from base and different from each other.
|
If there are no conflicting chunks, it is often safe to accept Perforce's generated merge file, since 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 foo#n
<text>
==== THEIR VERSION foo#m
<text>
==== YOUR VERSION foo
<text>
<<<<
|
Choose the text you want to keep; delete the conflicting chunks and all the difference markers.
Options
|
-am
-af
-as
-at
-ay
|
Skip the resolution dialog; resolve the files automatically as follows:
- -am: Automatic Mode. Automatically accept the Perforce-recommended file revision: if theirs is identical to base, accept yours; if yours is identical to base, accept theirs; if yours and theirs are different from base, and there are no conflicts between yours and theirs; accept merge; otherwise, there are conflicts between yours and theirs, so skip this file.
- -ay: Accept Yours, ignore theirs
- -at: Accept Theirs. Use this flag with caution, as the file in the client workspace will be overwritten!
- -as: Safe Accept. If either, but not both, of yours and theirs is different from base, accept that revision. If both are different from base, skip this file.
- -af: Force Accept. Accept the merge file no matter what. If the merge file has conflict markers, they will be left in, and you'll need to remove them by editing the file.
|
|
-n
|
List the files that need resolving without actually performing the resolve.
|
|
-v
|
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.
|
|
-b
|
(old flag, equivalent to -t. No longer "officially" documented, but still supported. Changed to -t for its equivalence to p4 diff's and p4 diff2's -t flag.)
|
|
-f
|
Allow already-resolved but not yet submitted files to be resolved again.
|
|
-t
|
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 P4MERGE is set to a utility that can do such a thing.
|
|
g_opts
|
See the Global Options section.
|
Usage Notes
Can File Arguments Use
Revision Specifier?
|
Can File Arguments Use
Revision Range?
|
Minimal Access Level Required
|
|---|
|
No
|
No
|
open
|
- p4 resolve works only with files that have been scheduled for resolve. Three operations schedule files for resolution:
- Integrating the file with p4 integrate.
- Submitting an open file that was synced from a revision other then the current head revision; the submit will fail, and the file will be scheduled for resolve.
- Instead of running p4 submit, running p4 sync on the open file. Nothing will be copied into the client workspace; instead, the file will be scheduled for resolve. (The only benefit of scheduling via p4 sync instead of via a failed submit is that the submit will not fail).
- When p4 resolve is run with no file arguments, it will operate on all files in the client workspace that have been scheduled for resolve.
Related Commands
|
To view a list of resolved but unsubmitted files
|
p4 resolved
|
|
To schedule the propagation of changes between two separate files
|
p4 integrate
|
|
To submit a set of changed files to the depot
|
p4 submit
|
|
To copy a file to the client workspace, or schedule an open file for resolve
|
p4 sync
|
|