I'm trying to merge main stream to development stream and some files need to be resolved. On resolve I have an error:
filepath tampered with before resolve - edit or revert.
I tried to solve it as described here, but without success.
This is what verify command shows me:
for the target
filepath - branch change 9070 (text) A3269695246A89D21F341D8A5BB70B5B
for the source
filepath - edit change 22793 (text) 171BA2F3E0FFCEF3F7A34FDB7A2CEF69
filepath - add change 9049 (text) A3269695246A89D21F341D8A5BB70B5B
What do branch change, edit change, add change mean? Why is the MD5 identical but I still have an error? How to solve?
Perforce's client-server architecture is confusing you a bit here: the 'verify' command is reporting on the state of the files on the server, but the 'tampered with before resolve' message from 'p4 resolve' is alerting you to a problem with the state of the files on your client.
It appears, from the little bit of information that you provided, that:
Change 9049 added the source file, with digest A3269...
Change 9070 branched that source file to the target. Of course, the digest is the same for source and target, since the branch was a perfect copy of the file.
Change 22793 modified the source file, and hence its digest changed
You are then trying to integrate change 22793 from the source to the target.
This integration would be a straightforward "safe resolve" in most cases, because the file was changed only in the source, and the target was a perfect copy of the previous revision of the source.
However, the resolve command looked on your actual workstation copy of the target file, and discovered that the file that you have there is not a file with digest A3269...
Since the 'resolve' command was just about to replace your copy of the target file on your workstation with the merged result, it doesn't want to do that if there is a possibility that you made changes to that file (without opening the file for edit) that you don't want to lose.
So 'resolve' is trying to tell you to have a look at the copy of the target file that is currently on your workstation (using your text editor, e.g.), and see if you actually made changes to that file.
If you did, and you want to save those changes, then you can't perform this integration at this time; you need to instead open the file for edit (using 'edit -k' to retain your modified copy of the file, of course) so that Perforce can merge your edited copy with the changes from change 22793.
If you didn't make changes to the target file, or if you made changes but you don't want them, then you need to discard those changes explicitly, for example by:
reverting the pending integration to the target file
Running 'p4 sync -f target-file'
This is the sort of information that 'resolve' is trying to communicate in that very terse
filepath tampered with before resolve - edit or revert.
I also have faced this issue while executing p4 resolve -am for some file. the solution is to do p4 edit <filename> and then execute p4 resolve -am for that file.
It means that your local was edited without the app knowing about it (e.g., you forgot to do "p4 edit" first). I believe I've seen this when doing an integrate then changing the file before submitting it, too.
Related
I use Perforce to manage a project that contains some binary files (Excel, Word and Visio diagram files).
I'd like to know the safe way to update my local version of such files from the latest version available on Perforce, without corrupting/damaging/overriding the local changes. (Local changes are made locally and not submitted to Perforce yet)
Locks don't seem to solve the problem because it helps only in concurrent submission of files.
p4 reconcile to make sure that any local changes are correctly reflected in your pending changelist(s).
p4 sync as normal. Opened files will not be overwritten by a p4 sync.
If you're following the standard Perforce workflow of always opening files for edit before you modify them (i.e. you never override the "read-only" flag on your local files), you can skip step 1 and just sync at any time without fear.
p4 resolve to handle any files that have been modified both locally and in the depot.
Note that Perforce's built-in merge logic will only handle text files, and so resolve will by default offer only a binary yours/theirs choice for binary files (at will overwrite your local changes, and ay will ignore the depot changes). If you have a merge tool that can handle your binary format, you can do:
p4 set P4MERGE=your_merge_tool
p4 resolve -t
m
to invoke your merge tool as part of the resolve process. See the documentation on the P4MERGE variable for more information how this tool will be called (you may need to wrap it in a script if it doesn't follow the base theirs yours merged calling convention): https://www.perforce.com/manuals/v17.1/cmdref/Content/CmdRef/P4MERGE.html
I have a few files that have been edited by an external IDE, I forgot to Check Out the files before making the changes however when I look at the files through P4V the files have changed but the indicator for the file itself shows as nothing has changed. How can I ensure my changes are committed without loosing what I have done?
One way I was thinking was to making a copy of the file, revert, check out, copy content or replace file.
That is OK with a few files but what happens when you have done so with hundreds of files?
The "check out" command doesn't modify the local file, so you can just do that on its own without having to make a backup copy of the file first. (What you want to avoid doing is "get latest", although if the local files are writable, Perforce will automatically balk at updating them by default because of this exact situation.)
If you have lots of files that might or might not have been modified in different ways, use Actions > Reconcile Offline Work, or "p4 reconcile" from the command line. This will find the locally modified files and open them for the appropriate action.
The P4V way to do this is called "Reconcile Offline Work": http://www.perforce.com/perforce/doc.current/manuals/p4v/Offline.html
Or, at the command line, you can use 'p4 reconcile': http://www.perforce.com/perforce/doc.current/manuals/cmdref/p4_reconcile.html
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
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.
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
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.
At this point, you can execute p4 sync to actually perform it.
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.
(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.
p4 resolve -af :: perform merging manually. Its output will list out files (of course with their path).
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.
To let you understand my problem, i must give some brief explanation about the way my client application works.
First, we create workspaces with allwrite set, this is because our programming language (PowerBuilder) does not writes directly to txt files, it writes to 'pbl' files, which are binary.
However we dont version pbl files and to be able to version each object inside a pbl we need to run some cmdcommand, which will output the classes within the pbl file to text files (one file per class), these text files is what Perforce must version.
The problem now is that the pbls are being listed as modified files (in fact they are), but we dont want them to be marked as modified.
I could put them in a ignore file, but there are some Pbls in the repository which must be synced.
I know i could specify in the ignore file to ignore Pbls except the Pbls which are in the repository, but then these specific pbls would keep showing up as modified files when i run a reconcile..
What i want is to have the PBL file exactly the way it was before running the reconcile, unopened by perforce but modified.
Its would be ok, if i could revert them without undoing its modifications...
Or if i could run a reconcilefor all the files, except the pbls.
Does anyone knows a way to do that? Thank you.
You can revert files without refreshing their content from the repository by running 'revert -k': http://perforce.com/perforce/doc.current/manuals/cmdref/p4_revert.html
I did a merge of bunch of files in perforce from one project into another. Turns out one of the file (VC++ .rc) file didn't merge properly and can't even open this in IDE as a result. I just want to remerge this single file again and leave the rest as is. Is this possible?
I did try 'rollback' on the file in target project but haven't checked in yet. Than I tried to re-merge/integrate just this file but it doesn't really work.
Perforce has a couple of suggestions in their knowledgebase: http://kb.perforce.com/article/517
Essentially what you probably have to do is to "update" the .rc file to the revision prior to the failed merge (probably using rollback) and then re-integrate that file. If it mumbles something about already having been integrated you should be able to use the "force" flag (-f) for p4 integrate.