Totally confused with the strange behavior of "p4 sync". Tried running the following commands
Note: The filename is not present in workspace
p4 sync //depot/filename
--- shows that files are up-to-date
p4 have //depot/filename
--- shows files not on client
Thought may be the perforce server thinks the file is present in its client's have database. So deleted the file using
p4 sync //depot/filename#none
--- shows files up-to-date
p4 sync //depot/filename#head
--- shows files up-to-date
Finally when I say
p4 have //depot/filename
--- shows files not on client
Then I did
p4 sync -f //depot/filename#head
--- shows //depot/filename - deleted as c:/workspace/filename
and in the end
p4 have //depot/filename
--- shows file not on client.
Any idea what could be the issue here?
Run "p4 files //depot/filename" and you will see that it is a deleted file.
If an older version of the file were present on your client (i.e. "p4 have" said there was something there), "p4 sync" would remove it. Since the file is already not present on your client, you are already "up to date".
Running "p4 sync -f" forces the issue and attempts to delete the local file even though the have table says nothing is there. (If you'd added a brand new file in its place and hadn't done "p4 add" yet, that file is now lost forever -- be careful when using "p4 sync -f"!)
Related
I want to be able to sync ONLY the differences in the depot into my workspace.
I do not want to re-sync all the source files which already match.
I currently can see the difference with this command:
p4 diff -sd //depot/source/...
But when trying to use this command to sync the depot differences to my local workspace:
p4 diff -sd //depot/source/... | p4 -x - sync -f | p4 //depot/source/...
I receive this message in the terminal:
"- must refer to client"
Note: Prior to performing all of the above command I set my client using
p4 set P4CLIENT=MYWORKSPACE
To sync only the files that have been updated on the server since you last synced, do:
p4 sync
The default behavior of the p4 sync command is to sync only changed files; you don't need to perform any special gyrations to make that happen.
The server's notion of what's different between the server and your workspace is dependent on its records of what it sent you the last time you synced. If you've messed around with your workspace in unsupported ways (i.e. you've modified files that Perforce made read-only without "opening" them for modification), those records have been invalidated. You can fix this one of two ways, depending on what you want to do with your modifications:
p4 reconcile
will open the files you modified, allowing you to choose between reverting the modifications or submitting them.
p4 clean
will simply overwrite your modifications, similar to a p4 sync -f, but p4 clean will do a diff to figure out which files you modified and will only re-sync those files.
i'm having this situation
when i try to run p4 edit <file>, it says
- can't edit (already opened on this client)
However, when i ran p4 opened <file> (with the -a and -x option), it says
- - file(s) not opened on this client.
I'm now left in this limbo state.
I can not check out the file,
i can not revert the file,
and i can not check in the file.
How can i fix this? And what happened actually?
First -- double check that all the file paths you stripped out of your question actually match each other. The legitimate way to get this error is if you're trying to edit a depot file that's already open under a different local path on the same client (because you opened it and then changed your client view), and you're trying to reopen the same depot file via the "new" local path while it still has pending changes in the previous location. Make sure you're running p4 opened <file> and p4 revert <file> on the same exact depot path that was returned by the can't edit error.
Once that's eliminated:
This error being thrown when it shouldn't is usually a symptom of an internal database inconsistency in the Perforce server -- the depot file is recorded in the db.locks table as being open on your client, but the corresponding client file isn't in the db.working table.
The easiest way to fix this is for the admin to run p4d -xf 925 on the server root; this is a repair command that looks for this exact inconsistency and should repair it by pruning out unmatched db.locks entries.
p4d -xx will also fix it (this command scans for a set of different inconsistencies and writes a journal patch file to repair them).
I have a workspace with set of files.But i observed that when i delete a file from perforce and do "p4 sync".The file is getting not deleted from the workspace.
But p4 sync -f deletes the file.
p4 sync will only delete a file from the workspace if:
the head revision of the depot file is deleted (check p4 files FILE)
you are currently synced to a different (not deleted) revision of the file (check p4 have FILE)
you do not currently have the file open (check p4 opened FILE)
The only one of these conditions that is affected by the -f flag is #2, so I suspect you had the file in your workspace but weren't on record as having synced it from the server (e.g. the file was put there outside of Perforce, or there was a sync -k, or something like that).
I have deleted some files/folders in my local machine but I did not commit the changes to repository.
How to get the deleted files back?
I am not getting the deleted files after performing the p4 sync -f. Why I am not getting the deleted files after the force sync?
If you haven't reverted the changes Perforce will still think you want to delete those files so won't restore them.
You need to go to the pending changelist and do a "revert" on those files to get them back.
Use the "p4 revert" command:
p4 revert -c default //...
This "revert[s] every file open in the default changelist to its pre-opened state."
Source
If you don't want to revert all the files, move the files you want to revert to a separate changelist and use the "-c" option.
If you only have a few files to revert you can specify the name of the file:
p4 revert lib/libopenssl.a include/openssl.h
for example, reverts exactly those two files (thanks to Bryan).
I have a branch that I created using p4 integrate but now the merge isn't behaving how I expect. When I merge, I get the following:
$ p4 merge -n ISSUE-49/... trunk/...
...
//depot/products/theProduct/trunk/some/directory/somefile.conf#1 - sync/delete from //depot/products/theProduct/ISSUE-49/some/directory/somefile.conf#1
...
That file was added on the ISSUE-49 branch (not deleted) so I don't understand why it wants to delete it.
When I try and use p4 integrate, I get:
$ p4 integrate -n ISSUE-49/... trunk/...
...
//depot/products/theProduct/trunk/some/directory/somefile.conf#1 - branch/sync from //depot/products/theProduct/ISSUE-49/some/directory/somefile.conf#1
...
It looks like it's trying to do a branch instead of a merge. Is it? How can I safely merge my changes from ISSUE-49 back into trunk?
I am trying to do this from the command-line on Linux using p4 2012.1. I have p4v 2013.3 on my Windows machine. I could use that if it would be easier.
A "merge" operation doesn't necessary always result in an "integrate" revision -- it depends on the current state of the target file and the changes made in the source file.
A "branch" revision is the first revision of a new file that is created as a copy from some other file. A "delete" revision represents a file that does not actually exist (usually this is a placeholder for a file that previously existed and has been deleted, but it can also be a placeholder for a file that has never existed).
The difference between "p4 merge" and "p4 integrate" is that with "p4 integrate" the file is opened for "branch" immediately rather than scheduling a resolve. If you run "p4 merge" followed by "p4 resolve -am" the file will be opened for "branch" exactly as if you'd run "p4 integrate".
Summary: everything is fine. Since the file does not exist in the trunk yet, a normal merge from ISSUE-49 will create it in the trunk as a new file. Whether you run "p4 integrate"+"p4 resolve" or "p4 merge"+"p4 resolve", the file will be opened for "branch", which is the action that creates it as a new file that is identical to the ISSUE-49 file.