Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to sync locally modified file with server revision in perforce

Tags:

perforce

I'm updating a locally modified file with the server revision so that I have all the latest changes (that other developers made while I was working on the file). I've already tried p4 sync. Does anyone know the correct way to do deal with this?

Thanks

like image 685
Niraj Avatar asked Sep 05 '25 02:09

Niraj


2 Answers

If the file is opened for edit, and you have already run 'p4 sync', then you should have seen a message like:

$ p4 sync
//depot/main/b#2 - is opened and not being changed
... //depot/main/b - must resolve #2 before submitting

What this means is that Perforce is ready for you to merge your changes together with the changes from the new revision.

Perforce calls this process "resolving" the changes, and has told you that you must resolve them before submitting the file.

When you are ready to merge your changes with the new changes from the new revision, run:

$ p4 resolve

Many people find this process of merging the changes a bit complicated, and prefer to use a GUI tool. Try downloading the P4V tool from the Perforce website and it will help you merge the changes using a visual merge tool.

If you instead decide that you do not want to keep your local changes, and would prefer to discard them, and use the latest version of the file instead, you can discard your changes by running:

$ p4 revert

But be careful! This will lose all the unsubmitted changes that you have made to your file! The same is true of the 'sync -f' command and the 'p4 clean' command; these commands tell Perforce that you don't want your locally-made unsubmitted changes, and Perforce should replace the file with a clean copy from the server.

like image 62
Bryan Pendleton Avatar answered Sep 07 '25 09:09

Bryan Pendleton


I will add more detail on Bryan's answer especially about all sequence of syncing, and fixing merge conflicts; assume that this is based on CLI p4.

Let's say you have locally modified files that upstream also has some updates for the same files since you've modified it locally.

Sanity steps I would do is the following

  1. p4 sync -n :: with -n this is dry-run which it won't actually have any effect or perform anything yet, but will return output if it really performs. For the specific situation we're in right now, you probably want to look for the line that has ... in front + the line above it which says is opened and not being changed. With our situation, this means upstream files has updates for the file you've opened and probably made some changes to it. It needs to be resolved.
  2. At this point, you can execute p4 sync to actually perform it.
  3. p4 resolve -n :: again with -n which means dry-run. This is to check whether there's any outstanding conflicts you need to resolve as the result of your sync.
  4. (if the output from 3. is not No file(s) to resolve.) p4 resolve -am :: this will perform conflict resolution automatically. It will try merging but will not do anything if there's any merge conflicts for target file. Its output will list out the result of each file. For files that it leaves out, there will be non-zero conflicts in the output.
  5. p4 resolve -af :: perform merging manually. Its output will list out files (of course with their path).
  6. From 5, edit each files as seen in the output. Search for ORIGINAL or THEIRS or YOURS then delete unwanted section, or merge things together as needed. When finish for each file, just save and quit. Do this for all files.

PS. More info for 6. Actually you can specify which merging resolution policy you want it to happen in which it can be

  • p4 resolve -at :: accept changes from upstream (accept THEIRS)
  • p4 resolve -ay :: ignore changes from upstream, only accept what you have locally (accept YOURS)

Also keep in mind, THEIRS doesn't need to always be upstream changes from depot, but if can mean a changelist that you just unshelved into your workspace locally.

like image 21
haxpor Avatar answered Sep 07 '25 10:09

haxpor