I need to find out what is the last revision Synced to my workspace but using the P4JAVA API, Any help??
According to the documentation for FileSpecBuilder you can include a rev specifier with the path, so if you change this:
makeFileSpecList("//depotname/path/...")
to this:
makeFileSpecList("#workspace")
it seems like that ought to do the trick.
Related
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'd like to omit an app-specific directory from the revision control check done by Origen:
origen rc mods
Is there something similar to a .gitignore?
Yes, you can set the following in config/application.rb:
config.unmanaged_dirs = %w(some_dir some/other/dir .some_hidden_dir)
config.unmanaged_files = %w(some_file some/other_file.blah *.blah)
Paths should be given relative to Origen.root and as this is applied within the origen rc command it should work with any revision control backend. Although, if you are using Git then it is recommended to just use .gitignore, this feature is intended to replicate that feature for lesser RC tools.
See the default list of ignored files/dirs for other examples: https://github.com/Origen-SDK/origen/blob/master/lib/origen/revision_control.rb#L9
I am trying to populate a task stream with an older revision than #head.
So I created a task stream, and did not chose to automatically branch any files.
Then I try :
>p4 populate -r -S //depot/dev //depot/main/...#some_label_vXXXX
Label 'some_label_vXXXX' is restricted to use on server 'Edge', not on server 'MASTER'.
I am connected to the edge server so I am not quite sure what is the issue there. If I need to have a global label to be able to branch, is there a way to convert an existing local to global label ?
Anyway, I try using a changelist instead.
>p4 populate -r -S //depot/dev //depot/main/...#1456175
//depot/main/...#1456175 - no target file(s) in branch view.
What happens there ? Is this an issue with the FromFile ? And what would be the proper way to populate a task stream using an existing label/changelist ?
Playing with P4V, it seems the command executed is (and this works) :
>p4 populate -o //depot/main/...#1456175 //depot/dev/...
I am still interested in understanding why the '-rS' does not work.
In this syntax:
p4 populate -r -S //depot/dev //depot/main/...#1456175
//depot/main/... is limiting the toFile, which is not what you want. This should work:
p4 populate -r -S //depot/dev #1456175
Giving the stream name already generates the fromFile->toFile view, so there's no need to specify either of them a second time.
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.
I would like to know if it is possible to find who committed what with P4.
The best would be getting something like:
user committed: com/app/Class.java, com/class/Class2.java etc..
Edit:
Ok I can use:
p4 changes -m 5 -u user //dev/project/...
But this doesn't give me which files have been committed.
Have any idea?
Thanks a lot guys!
If you want to identify the last user to modify a the file, you could use something like:
p4 filelog -m 1 //dev/project/...
This will provide information about the last change to each file, including the name of the user that submitted the change.