I'm seeking assistance to determine max changeListId/revisionId of the my local Perforce view using the p4java API. I've tries using the com.perforce.p4java.client.Client to create a list of FileSpec, but changeListId is not set on any of the files when querying the Client - Server is OK.
I am seeking the client's current revision number to help me determine if it is in synch with the server or not. Details such as this sample from 'p4 cstat' would be perfect:
p4 cstat
... change 1
... status have
......
... change 17
... status partial
... change 18
... status need
p4java p4java version 2012.3
Thanks in advance!
A common way to do this is to use "p4 changes -m q ///...#have". With P4Java you would use the GetChangelists() method on IOptionsServer with the appropriate filespec and version specifier.
Related
I am facing a weird behavior in perforce submitted files, after p4 integrate
Scenario
Repo contains C# code and the built DLL. I wished to integrate a changeset from one branch to another
so I am following the steps which I had discussed, a while ago
The .cs files doesn't complain. If there is resolve conflict in the DLL, I choose either of Accept Source or Accept Target without much care. Reason being, I always rebuild the DLL before submitting
Issue
The DLL which was built in local workspace and reflected in the changeset is correct. I tested it locally and do p4 submit. But to my amazement, the DLL submitted is not the one which I had built. Instead the one which came from that other branch was submitted
Confusion
I thought that with perforce, when a file is opened in a changeset, always the latest(local) copy will be submitted. That is why I don't pay much attention if there are conflict reported in DLL
Isn't that correct ?
Why would the submitted file be different from my workspace version ?
When you "accept source" you're recording that you want the target file to be an exact copy of the source file; consequently, if you submit the file, it's not even transferred from the workspace (in order to save time) -- instead it's just copied server-side. If you tampered with the workspace file, this leads to the situation you describe where the workspace is now inconsistent with the depot, just like if you'd modified a file that wasn't open for edit.
If you submit with the -t flag (for "tamper checking"), it will check for tampered files by comparing what's in your workspace with what should be in your workspace according to the resolve options you picked:
C:\Perforce\test\integ>p4 integ source target
//depot/integ/target#2 - integrate from //depot/integ/source#3
C:\Perforce\test\integ>p4 resolve -at
c:\Perforce\test\integ\target - vs //depot/integ/source#3
//Samwise-dvcs-1509687817/integ/target - copy from //depot/integ/source
C:\Perforce\test\integ>echo tampertampertamper >> target
C:\Perforce\test\integ>p4 submit -t -d "submitting tampered file"
Submitting change 190.
Locking 1 files ...
integrate //depot/integ/target#3
//Samwise-dvcs-1509687817/integ/target tampered with after resolve - edit or revert.
Submit aborted -- fix problems then use 'p4 submit -c 190'.
Some file(s) could not be transferred from client.
If you p4 edit the file, it's changed from a pure copy to an edit, and will be read from the workspace instead of from the source file:
C:\Perforce\test\integ>p4 edit target
//depot/integ/target#2 - reopened for edit
C:\Perforce\test\integ>p4 submit -c 190
Submitting change 190.
edit //depot/integ/target#3
Change 190 submitted.
In an analysis of the history in our perforce depot, I need to identify those changes where a full integration from another branch was performed and also find out the exact change number of the source of that integration. Unfortunately, even though such a full integration is a common operation, I could not find any easy and reliable way to detect it in the history. Please let me know if I missed something.
In any case: via a set of scripts using 'p4 filelog' and matching up revision numbers, I managed to find all candidate changes and their respective integration source change. What I am missing is a means to distinguish full integrations from cherry-picks or partial integrations limited to a subdirectory. For this, the closest I could find is the 'p4 interchanges' command, which does exactly the thing I need, except for the problem that the 'toFile' argument cannot have an '#' revision specification.
I would have hoped that
p4 interchanges //depot/sourcebranch#123400 //depot/targetbranch#123499
would tell me whether any changes were missing in the integration point I found, but it only gives the error 'A revision specification (# or #) cannot be used here.' - which matches the documentation.
Is there any other means to examine integration points in the p4 history to distinguish cherry-picks from full merges?
Use the undoc p4 integ -C changelist command:
p4 integrate -1 -2 -C changelist# -Rlou -Znnn
... The -C
changelist# flag considers only integration history from changelists
at or below the given number, allowing you to ignore credit from
subsequent integrations. ...
Hence:
p4 integ -n -C 123499 //depot/sourcebranch/...#123400 //depot/targetbranch/...
should tell you whether sourcebranch#123400 was fully integrated into targetbranch#123499. If you use -C 123498 in theory the difference in the output will show you which files were integrated.
There are probably some edge cases around deleted files -- e.g. if you integrate a deleted file into a file that's deleted at the head revision, it will report "up to date" regardless of integration history, so I can imagine that a file that was skipped for that reason but then subsequently re-added might give a false positive with the above method. (Or it might not -- I have vague memories of possibly fixing that scenario, but undoc bug fixes don't show up in the relnotes...)
Here's an example where foo#2 was integrated into bar#3:
sams-mbp:test samwise$ p4 filelog ...
//stream/main/test/bar
... #2 change 4 delete on 2019/07/21 by samwise#samwise-dvcs-1517552832 (text) 'delete'
... #1 change 3 branch on 2019/07/21 by samwise#samwise-dvcs-1517552832 (text) 'branch'
... ... branch from //stream/main/test/foo#1
//stream/main/test/foo
... #2 change 6 edit on 2019/07/21 by samwise#samwise-dvcs-1517552832 (text) 'edit'
... #1 change 2 add on 2019/07/21 by samwise#samwise-dvcs-1517552832 (text) 'add'
... ... branch into //stream/main/test/bar#1
sams-mbp:test samwise$ p4 integ -n -C 2 foo#2 bar
//stream/main/test/bar#2 - branch/sync from //stream/main/test/foo#1
sams-mbp:test samwise$ p4 integ -n -C 3 foo#2 bar
foo#2 - all revision(s) already integrated.
With -C 2 (before the branch), we see a replay of the integration as it would have happened as of that point in time. With -C 3 (the changelist of the branch), we see "all revisions integrated" because by that point in time it had already happened.
After continuing to try out all combinations of arguments, I finally found a solution that works for me:
p4 interchanges -b SOURCE_to_TARGET //depot/targetbranch/...#targetchange
will print out all changes on the source branch that are missing on targetbranch#targetchange. It will return only changes older than targetchange. If this list contains no changes older than sourcechange, the targetchange was a full integration.
The command may take considerable time to complete when the returned list is long. Unfortunately, I can't find a way to truncate this search, but I can live with that.
As it seems, some of this functionality was buggy up to server version 2018.2 which might have caused difficulties in my earlier attempts.
I'm running p4 interchanges -b my_branch, and I get a ton of results, the first one being a changelist that we integrated a long time ago.
So I try to integrate again, but p4 integrate -b my_branch //...#changelist,#changelist just returns "All revision(s) already integrated".
The only way to unblock this is to do a forced integration (-f in the integrate command) and then simply accept target (-at when resolving), and that works - p4 interchanges then no longer lists this changelist.
But how can Perforce get into this state to begin with? This happened after we've done a bunch of integrating across multiple branches, but I nothing that I'd think would cause a changelist to become "unintegrated" somehow.
This is on a 2014.1 server.
Thank you for specifying your server version.
The 'p4 interchanges' command can give the "All revision(s) already integrated" message with misleading results when cherry-picking is involved.
There is a command line example here:
http://answers.perforce.com/articles/KB_Article/Cherry-Picking-Integrations
You could also be affected by a bug that was patched in 2014.1 listed here in the server release notes:
http://www.perforce.com/perforce/doc.current/user/relnotes.txt
Bugs fixed in 2014.1 PATCH5
#880506 (Bug #71725) **
The istat.mimic.ichanges configurable controls the reporting
of revisions between stream and parent. If set, istat will
not report cherry-picked revisions already present in the target.
The default behavior will report any changes not credited, even
when the content may already be in the target.
If you would like, you can pull the most recent build of the server P4D for your OS from our ftp site: http://ftp.perforce.com/perforce/r14.1/
REFERENCE
http://answers.perforce.com/articles/KB_Article/Integration-Changes-Reporting
I am using following command to sync B vob files from A vob
clearfsimport -master -follow -nsetevent -comment $2 /vobs/A/xxx/*.h /vobs/B/xxx/
It works fine. But it will check in all the changes automatically. Is there a way to do the same task but leave the update files in a check out status?
I want to update the file for B from A. Build my programme, and then re-cover the branch. So if the updated files is an check out status, I can do unco later. Well with my command before, everything is checked in. I cann't re-cover my branch then.
Thanks.
As VonC said, it's impossible to prevent "clearfsimport" to do the check in. And he suggested to use a label to recover back.
For me, the branch where I did "clearfsimport" is branched from a label.Let's call it LABEL_01. So I guess I can use that label for recovery. Is there an easy way (one command) to recover the files under /vobs/B/xxx/ to label LABEL_01 ? I want to do it in my bash script, so the less/easy the command is, the better.
Thanks.
After having a look at the man page for clearfsimport, no, it isn't possible to prevent the checkins.
I would set a label before the clearfsimport, and modify the config spec for the new version to be created in a branch (similar to this config spec).
That way, "re-cover" the initial branch would be easy: none of the new version would have been created in it.
I want to create a p4 branch based on branch mvs_1211_hf at this label CC2P4_MVS_1211_HF_PILOT1, but the p4 command response is not my expectation. Anyone can help on this? Or is there any ways to create branch in p4? Thanks in advance!
Here is the p4 command i run:
p4 integ //depot/MVS_IMPORT/mvs_1211_hf/tms_dev/...#CC2P4_MVS_1211_HF_PILOT1 //deport/1211_hf/...
Here is the p4 complains:
//deport/1211_hf/... - must refer to client 'ruilong_mvs_1211_hf_pilot1'.
Best regards,
Ruilong
Typical errors include the ones previously mentioned, plus:
//depot1/... - must refer to client 'clientname'.
Check the client workspace view by running:
p4 client -o clientname
Check the "View" lines in the client workspace specification to confirm that the file specification used in your Perforce command (or appearing in the error message) falls within your workspace view.
If needed, change the client workspace by running:
p4 client clientname
Find more at: http://answers.perforce.com/articles/KB_Article/Common-Permissions-and-File-Access-Problems
Thanks
I received this error, when the path simply did not exists... had a typo :/
The must refer to client <client> error is the generic error given when an absolute path is neither a valid depot path nor a valid client path within the context of the current client. In this case, the cause of the error is that you typed //deport instead of //depot.
It would be more accurate for the error to say must be a depot path or a client path referring to current client <client>, but Perforce error messages tend to err on the side of brevity.