Concurrent development means multiple people can work on the same file at the same time. This enables an efficient team workflow, but conflicts may arise if two users change the same file, or you edit a file version that is not the latest. P4V provides a few features and tools for managing these conflicts.
For developers working with text files, the preferred option is to checkout and edit your files, and then merge the changes into newer versions if needed. For folks sharing binary files such as Office docs, images and other multimedia, locking the file on checkout works best.
Let’s walk through a Merge using P4V. Before getting started on any work, you can see the status of a file by looking at the icon. A blue checkmark on the file indicates it’s checked out by other users. A quick mouseover shows Joe Coder has this file now.
We also need to make some changes to EBolt so we drag and drop it into the Pending Changelist pane. The red check mark shows we now have this file checked out. Other users will see the blue check on EBolt letting them know we are working on the file.
We open the file to make a quick edit, and save it.
Now we are ready to Submit our change, but we see from the yellow triangle there has been some check-ins and our file is now out of date. We need to update our workspace to the latest version so we select Get Latest Revision on EBolt.
The question mark on the file indicates we have a conflict. We will not be allowed to submit this file until the resolve is complete so we context click and select Resolve.
The Resolve dialog appears and we are presented with a few options. Accept Source means take the new file from the depot and discard the your changes. Accept target is the opposite. It will replace the file currently in the depot with yours when you perform a Submit. Accept Merged will automatically merge the files together if there is no line-by-line conflict. We will select Run Merge Tool to perform the merge manually.
This is P4Merge, P4V’s built-in three-pane merge tool. In the middle pane, we can see the original file we checked out called the “base.” On the left are the changes conflicting with ours “source,” and on the right are the changes we entered, “target.”
All three options are presented in the edit window down below. Let’s say our edit is the best option and pick “target” by selecting the lucky charm character associated with that line. Or better yet, let’s take advantage of the editor window and make a completely different change.
Once the merge is complete, you save the file, and close the merge tool. A verification dialog appears to ensure we want to save the new merged file over our original edits. When we select “yes” the merge operation is complete in our local workspace and the file is ready to be submitted to the depot.
Next, we do a quick right click to bring up the submit dialog box, enter a short changelist description, and hit the submit button. Now the newest version of EBolt is in the depot along with all previously submitted versions.
For binary files such as Office docs, graphics, audio and video, it is easier to lock the file at checkout. This prevents others from submitting changes until yours are completed. The file lock is easy to engage. Once you checkout a file, it will appear in the Pending changelist with the usual red checkmark. Now context-click the file and select Lock or use the Cntl-L shortcut. Other users will now see the blue check mark and the lock icon letting them know you have it checked out. As a best practice, it’s good to use this only for binary files that cannot be merged together such as Office docs and media files such as graphics, audio and video.
Thanks for watching.