I'm going to execute a command like this.
p4 changes @2024/10/10:17:46:20 -s submitted -m 1 -u "my_usert_nr_*" //my/path/...
It's intention is:
Short: Please p4, provide me with the newest change of a group of users done before date X.
I'm using client version 2021.1 and refering to this manual with the help of the wildcard reference.
The command runs for a long time. If it returns, it might present a list of all change lists ever committed to the repo. so at least the -m and the -u parameter is disregarded.
I want to know why the command does not deliver the expected result. Does it work for you?
Strange thing is also, the -u parameter states, that Wildcards (*, %%x, ...) not allowed in 'zac*'. which I suppose is against the manual. Is my client to old, to support that?
In Perforce's command line parsing the named "flags" (anything starting with -) always go before the positional arguments. Any flag you pass after the first non-flag argument is treated as an additional positional argument. So in this command:
p4 changes @2024/10/10:17:46:20 -s submitted -m 1 -u "my_usert_nr_*" //my/path/...
-s, submitted, -m, etc are all being treated as file paths (because they follow the non-flag argument @2024/10/10:17:46:20). That's your first problem.
The second problem is that -u with wildcards requires a 2024.2 server (not client). This is a brand new feature as of literally a couple weeks ago, per the release notes:
Minor new functionality in 2024.2 (2024.2/2675662) (2024/10/31)
#2656556 (Job #121864) **
This change alters the -c option of 'p4 changes' to allow it to
work as a search pattern possibly with wildcards. Adding a -E flag
( or the long --client-case-insensitive flag) makes the matching
case-insensitive even on a case-sensitive server. Similar change
is also applied to the -u option. Note that we can have multiple
-u options and each can now be a search pattern that supports
wildcards and can start with '-' to exclude specific users. The -E
flag ( or the long --user-case-insensitive flag ) can be used to
control case-sensitiveness.
If you're not able to get your admin to upgrade the server to the absolute latest and greatest, you won't be able to use this feature.
The last problem is that if you pass two file/revision arguments separately:
@2024/10/10:17:46:20 //my/path/...
they are evaluated independently and the results are added together -- that's why you're getting so many results and why it takes so long! When you want to intersect a file specifier and a revision range (which is most commonly the case), you combine them into a single argument; the @ denotes where the filespec ends and the rev range begins.
So here's the command you want to run:
p4 changes //my/path/...@2024/10/10:17:46:20
The -s submitted is unnecessary because the revision range can only apply to submitted changes anyway. You can't use the -u with a wildcard, which in turn means that you can't use -m1 to limit the results (because the first result might be one that's not from one of those users).
So now you have all the changes in that path before that date, and from there you'll need to post-process a bit. I recommend grep and head (these come standard on Mac/Linux, and if you're on Windows you can install them easily). Use grep to grab changelists submitted by users matching the pattern:
p4 changes //my/path/...@2024/10/10:17:46:20 | grep -e " my_usert_nr_.*@"
and then head to just get the most recent changelist:
p4 changes //my/path/...@2024/10/10:17:46:20 | grep -e " my_usert_nr_.*@" | head -n1
If you're eventually able to upgrade to 2024.2, this becomes simply (note the flags before the file/revision specifier):
p4 changes -u "my_usert_nr_*" -m 1 //my/path/...@2024/10/10:17:46:20