Resolving Conflicts
This chapter tells you how to work in a team development environment, where multiple users who are working on the same files might need to reconcile their changes.
In settings where multiple users are working on the same set of files, conflicts can occur. Perforce enables your team to work on the same files simultaneously and resolve any conflicts that arise. For example, conflicts occur if two users change the same file (the primary concern in team settings) or you edit a previous revision of a file rather than the head revision.
When you attempt to submit a file that conflicts with the head revision in the depot, Perforce requires you to resolve the conflict. Merging changes from a development branch to a release branch is another typical task that requires you to resolve files.
To prevent conflicts, Perforce enables you to lock files when they are edited. However, locking can restrict team development. Your team needs to choose the strategy that maximizes file availability while minimizing conflicts. For details, refer to Locking files.
You might prefer to resolve files using graphical tools like P4V, the Perforce Visual Client, and its associated visual merge tool P4Merge.
How conflicts occur
File conflicts can occur when two users edit and submit two versions of the same file. Conflicts can occur in a number of ways, for example:
-
Bruno opens
//depot/dev/main/jam/command.c#8
for edit. -
Gale subsequently opens the same file for edit in her own client workspace.
-
Bruno and Gale both edit
//depot/dev/main/jam/command.c#8
. -
Bruno submits a changelist containing
//depot/dev/main/jam/command.c
, and the submit succeeds. -
Gale submits a changelist with her version of
//depot/dev/main/jam/command.c
. Her submit fails.
If Perforce accepts Gale's version into the depot, her changes will overwrite Bruno's changes. To prevent Bruno's changes from being lost, Perforce rejects the changelist and schedules the conflicting file to be resolved. If you know of file conflicts in advance and want to schedule a file for resolution, sync it. Perforce detects the conflicts and schedules the file for resolution.
How to resolve conflicts
To resolve a file conflict, you determine the contents of the files you intend to submit by issuing the p4 resolve command and choosing the desired method of resolution for each file. After you resolve conflicts, you submit the changelist containing the files.
Note
If you open a file for edit, then sync a subsequently submitted revision from the depot, Perforce requires you to resolve to prevent your own changes from being overwritten by the depot file.
By default, Perforce uses its diff program to detect conflicts. You can configure a third-party diff program. For details, see Diffing files.
To resolve conflicts and submit your changes, perform the following steps:
-
Sync the files (for example p4 sync //depot/dev/main/jam/...). Perforce detects any conflicts and schedules the conflicting files for resolve.
-
Issue the p4 resolve command and resolve any conflicts. See Options for resolving conflicts for details about resolve options.
-
Test the resulting files (for example, compile code and verify that it runs).
-
Submit the changelist containing the files.
Note
If any of the three file revisions participating in the merge are binary instead of text, a three-way merge is not possible. Instead, p4 resolve performs a two-way merge: the two conflicting file versions are presented, and you can choose between them or edit the one in your workspace before submitting the changelist.
Your, theirs, base and merge files
The p4 resolve command uses the following terms during the merge process.
File revision |
Description |
---|---|
|
The revision of the file in your client workspace, containing changes you made. |
|
The revision in the depot, edited by another user, that
|
|
The file revision in the depot that
|
|
The file generated by Perforce from
|
|
The final file resulting from the resolve process. |
Options for resolving conflicts
To specify how a conflict is to be resolved, you issue the p4 resolve command, which displays a dialog for each file scheduled for resolve. The dialog describes the differences between the file you changed and the conflicting revision. For example:
p4 resolve //depot/dev/main/jam/command.c c:\bruno_ws\dev\main\jam\command.c - merging //depot/dev/main/jam/command.c#9 Diff chunks: 4 yours + 2 theirs + 1 both + 1 conflicting Accept(a) Edit(e) Diff(d) Merge (m) Skip(s) Help(?) e:
The differences between each pair of files are summarized by p4
resolve. Groups of lines (chunks) in the
yours
, theirs
, and
base
files can differ in various ways. Chunks can be:
-
Diffs: different between two of the three files:
yours
,theirs
, orbase
-
Conflicts: different in all three files
In the preceding example:
-
Four chunks are identical in
theirs
andbase
but are different inyours
. -
Two chunks are identical in
yours
andbase
but are different intheirs
. -
One chunk was changed identically in
yours
andtheirs
. -
One chunk is different in
yours
,theirs
, andbase
.
Perforce's recommended choice is displayed at the end of the command line. Pressing ENTER or choosing performs the recommended choice.
You can resolve conflicts in three basic ways:
-
Accept a file without changing it (see Accepting yours, theirs, or merge)
-
Edit the merge file with a text editor (see Editing the merge file)
-
Merge changes selectively using a merge program (see Merging to resolve conflicts)
The preceding options are interactive. You can also specify resolve
options on the p4 resolve command line, if you know
which file you want to accept. For details, see
Resolve command-line options. To reresolve a resolved but unsubmitted file,
specify the -f
option when you issue the p4
resolve command. You cannot reresolve a file after you submit
it. The following sections describe the resolve options in more detail.
Accepting yours, theirs, or merge
To accept a file without changing it, specify one of the following options.
Option |
Description |
Remarks |
---|---|---|
|
Accept recommended file |
|
|
Accept edit |
If you edited the |
|
Accept |
Accept |
|
Accept |
Accept |
|
Accept |
Accept |
Accepting yours
, theirs
,
edit
, or merge
overwrites changes,
and the generated merge file might not be precisely what you want to
submit to the depot. The most precise way to ensure that you submit only
the desired changes is to use a merge program or edit the merge file.
Editing the merge file
To resolve files by editing the merge file, choose the
e
option. Perforce launches your default text
editor, displaying the merge file. In the merge file, diffs and
conflicts appear in the following format:
>>>> ORIGINALfile
#n
(text from the original version)
==== THEIRfile
#m
(text from their file)
==== YOURSfile
(text from your file)
<<<<
To locate conflicts and differences, look for the difference marker
">>>>
" and edit that portion of the text. Examine the
changes made to theirs
to make sure that they
are compatible with your changes. Make sure you remove all conflict
markers before saving. After you make the desired changes, save the
file. At the p4 resolve prompt, choose
ae
.
By default, only the conflicts between the
yours
and theirs
files are marked. To generate difference markers for all differences,
specify the -v
option when you issue the
p4 resolve command.
Merging to resolve conflicts
A merge program displays the differences between yours, theirs, and the
base file, and enables you to select and edit changes to produce the
desired result file. To configure a merge program, set
P4MERGE
to the desired program. To use the merge program
during a resolve, choose the m
option. For details
about using a specific merge program, consult its online help.
After you merge, save your results and exit the merge program. At the
p4 resolve prompt, choose am
.
Full list of resolve options
The p4 resolve command offers the following options.
Option |
Action |
Remarks |
---|---|---|
|
Help |
Display help for p4 resolve. |
|
Accept automatically |
Accept the autoselected file:
|
|
Accept edit |
If you edited the |
|
Accept |
Accept |
|
Accept |
Accept |
|
Accept |
Accept |
|
Diff |
Show diffs between |
|
Diff |
Show diffs between |
|
Diff |
Show diffs between |
|
Diff |
Show diffs between |
|
Edit merged |
Edit the preliminary merge file generated by Perforce. |
|
Edit |
Edit the revision in the depot that the client revision conflicts with (usually the head revision). This edit is read-only. |
|
Edit |
Edit the revision of the file currently in the workspace. |
|
Merge |
Invoke the command |
|
Skip |
Skip this file and leave it scheduled for resolve. |
Note
The merge
file is generated by the Perforce
service, but the differences displayed by dy
,
dt
, dm
, and d
are generated by your workstation's diff program. To configure another
diff program to be launched when you choose a d
option during a resolve, set P4DIFF
. For more details,
see Diffing files.
Example 28. Resolving file conflicts
To resolve conflicts between his work on a Jam readme file and Earl's work on the same file, Bruno types p4 resolve //depot/dev/main/jam/README and sees the following:
Diff chunks: 0 yours + 0 theirs + 0 both + 1 conflicting Accept(a) Edit(e) Diff(d) Merge (m) Skip(s) Help(?) e: e
Bruno sees that that he and Earl have made a conflicting change to the
file. He types e
to edit the merge file and
searches for the difference marker ">>>>
". The
following text is displayed:
Jam/MR (formerly "jam - make(1) redux") /+\ >>>> ORIGINAL README#26 +\ Copyright 1993, 1997 Christopher Seiwald. ==== THEIRS README#27 +\ Copyright 1993, 1997, 2004 Christopher Seiwald. ==== YOURS README +\ Copyright 1993, 1997, 2005 Christopher Seiwald. <<<< \+/
Bruno and Earl have updated the copyright date differently. Bruno
edits the merge file so that the header is correct, exits from the
editor and types am
. The edited merge file is
written to the client workspace, and he proceeds to resolve the next
file.
When a version of the file is accepted during a resolve, the file in the workspace is overwritten, and the new client file must still be submitted to the depot. New conflicts can occur if new versions of a file are submitted after you resolve but before you submit the resolved files. This problem can be prevented by locking the file before you perform the resolve. For details, see Locking files.
Resolving Branched Files, Deletions, Moves and Filetype Changes
Beyond reconciling changes to the contents of related files after integration, you can also determine how other kinds of changes are handled. For example:
-
You edit
header.cc
in the mainline while a coworker deletes it in the release branch (or vice versa). You integrate fixes in the release branch back to main. During resolve, you can decide whetherheader.cc
is deleted from the mainline or the action in the release branch is ignored, preservingheader.cc
in the mainline. -
A developer implement RCS keywords in source files in a development branch, and change their Perforce filetype from
text
totext+k
. The release manager wants to integrate new features from the development branch to the mainline, but does not want to enable keyword expansion in the mainline. During resolve, the release manager can choose to ignore the filetype change. -
The file
header.cc
is branched frommain
torel
. Subsequently, it's renamed toheaderx.cc
in main, and moved in the release branch to theheaders
subfolder.
Following are simple cases describing how you can resolve non-content
changes to related files. After a source file is branched to a target
file, changes are made as describe below, then you integrate the source
to the target. To choose the outcome, you specify the resolve options
at
("Accept Theirs") or ay
("Accept Yours") as follows:
-
The source is edited and target is deleted: the
at
option re-adds the source in the target branch. Theay
option causes the file to remain deleted in the target branch. -
The source is deleted and the target is edited: the
at
option causes the file to be deleted in the target branch. Theay
option retains the edited content in the target branch. -
The target file was moved after being branched: the
at
option moves the target file to the source file name and location. Theay
option retains the target file name and location. -
The filetype of the source file was changed after it was branched: the
at
option propagates the change to the target. Theay
option leaves the filetype of the target unchanged. If the differing filetypes do not conflict, you have the option of combining them. -
Files have been moved or renamed in conflicting ways: you are prompted to choose a path and filename. Example:
Resolving move to //depot/rel/headerx.cc Filename resolve: at: //depot/rel/headerx.cc ay: //depot/rel/headers/header.cc am: //depot/rel/headers/headerx.cc
By default, the p4 resolve command resolves all types
of change, content and non-content. To constrain the type of actions
that you want to resolve, specify the -A
option as
follows:
Option |
What is Resolved |
---|---|
|
Resolve attributes set by p4 attribute. |
|
Integrations where the source is edited and the target is deleted. |
|
Resolve file content changes as well as actions. |
|
Integrations where the source is deleted and target is edited. |
|
Renames and moves. |
|
Filetype changes. |
|
Charset changes. |
To perform more than one type of resolve, combine the options (for
example: -Abd
). By default, resolving is performed file
by file, interactively. To specify the same outcome for a particular
action (for example, propagate all moves), and avoid the prompting,
include the desired option on the command line. For example:
p4 resolve -Am -at
Resolve command-line options
The following p4 resolve options enable you to resolve directly instead of interactively. When you specify one of these options in the p4 resolve command, files are resolved as described in the following table.
Option |
Description |
---|---|
|
Accept the autoselected file. |
|
Accept |
|
Accept |
|
Accept the recommended file revision according to the following logic:
|
|
Accept the recommended file revision, even if conflicts remain. If this option is used, edit the resulting file in the workspace to remove any difference markers. |
|
Accept the recommended file revision according to the following logic:
|
Example 29. Automatically accepting particular revisions of conflicting files
Bruno has been editing the documentation files in
/doc
and knows that some of them require
resolving. He types p4 sync doc/*.guide, and all of
these files that conflict with files in the depot are scheduled for
resolve.
He then types p4 resolve -am and the merge files for all scheduled resolves are generated, and those merge files that contain no line set conflicts are written to his client workspace. He'll still need to manually resolve any conflicting files, but the amount of work he needs to do is substantially reduced.
Resolve reporting commands
The following reporting commands are helpful when you are resolving file conflicts.
Command |
Meaning |
---|---|
p4 diff [ |
Diffs the file revision in the workspace with the last revision you synced, to display changes you have made. |
p4 diff2 |
Diffs two depot files. The specified files can be any two file revisions and different files.
When you diff depot files, Perforce service uses its own diff
program, not the diff program configured by setting
|
p4 sync -n [ |
Previews the specified sync, listing which files have conflicts and need to be resolved. |
p4 resolved |
Reports files that have been resolved but not yet submitted. |
Locking files
After you open a file, you can lock it to prevent other users from submitting it before you do. The benefit of locking a file is that conflicts are prevented, but when you lock a file, you might prevent other team members from proceeding with their work on that file.
Preventing multiple resolves by locking files
Without file locking, there is no guarantee that the resolve process ever ends. The following scenario demonstrates the problem:
-
Bruno opens file for edit.
-
Gale opens the same file in her client for edit.
-
Bruno and Gale both edit their client workspace versions of the file.
-
Bruno submits a changelist containing that file, and his submit succeeds.
-
Gale submits a changelist with her version of the file; her submit fails because of file conflicts with the new depot's file.
-
Gale starts a resolve.
-
Bruno edits and submits a new version of the same file.
-
Gale finishes the resolve and attempts to submit; the submit fails and must now be merged with Bruno's latest file.
…and so on.
To prevent such problems, you can lock files, as follows.
-
Before scheduling a resolve, lock the file.
-
Sync the file (to schedule a resolve).
-
Resolve the file.
-
Submit the file.
-
Perforce automatically unlocks the file after successful changelist submission.
To list open locked files on UNIX, issue the following command:
p4 opened | grep "*locked*"
Preventing multiple checkouts
To ensure that only one user at a time can work on the file, use the
+l
(exclusive-open) file type modifier. For example:
p4 reopen -t binary+l file
Although exclusive locking prevents concurrent development, for some file types (binary files), merging and resolving are not meaningful, so you can prevent conflicts by preventing multiple users from working on the file simultaneously.
Your Perforce administrator can use the p4 typemap
command to ensure that all files of a specified type (for instance,
//depot/.../*.gif
for all .gif
files) can only be opened by one user at a time. See the
P4
Command Reference for details.
The difference between p4 lock and
+l
is that p4 lock allows anyone
to open a file for edit, but only the person who locked the file can
submit it. By contrast, a file of type +l
prevents
more than one user from opening the file.