Open topic with navigation

p4 resolve

Resolve conflicts between file revisions.

Syntax

p4 [g-opts] resolve [-a options] [-A options] [-d options] [-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 a p4 edit of file file.c, and Bob does the same thing. Alice p4 submits file.c, and then Bob tries to submit file.c. Bob’s submit fails because if his version of file.c were to be accepted into the depot, Alice’s changes to file.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:

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.

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:

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.

Non-Content-Related Resolves

Beyond differences in content, you can also resolve other types of difference between related files: filetype, deletion, branching, and moves and renames. For details, refer to the Helix Versioning Engine User Guide. To constrain the process to one type of resolve, use the -A option.

Each type of resolve is handled separately. For example, if a file has both a filetype conflict and a content conflict, you are prompted separately to specify how each is handled. To avoid file-by-file prompting when the desired outcome is the same for all resolves, include the -at or -ay option following the -A option. The following example illustrates how prompting is handled for different resolves.

Merging //depot/rel/fileb#1
Diff chunks: 1 yours + 0 theirs + 0 both + 0 conflicting
Accept(a) Edit(e) Diff(d) Merge (m) Skip(s) Help(?) ay: m
//depot/main/filez - resolve skipped.
Resolving move to //depot/main/fileb
Filename resolve:
at: //depot/main/fileb
ay: //depot/main/filez

Options

Usage Notes

• p4 resolve works only with files that have been scheduled for resolve. Three operations schedule files for resolution:

  • Integrating the file with p4 integrate or p4 merge.

    When scheduling files for resolve, p4 integrate selects the closest common ancestor as the base. The p4 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 running p4 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 with p4 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 and unicode files, the most likely cause is the presence of non-ASCII characters in the text file. Either remove the non-ASCII characters from the file before integration, or set P4CHARSET to utf8 and attempt the merge again.

Related Commands