commands like p4 changes work only for files how can I get latest synced cl for a directory. when I use these command s for directories I get this.
commands I tried
p4 changes -m1 "path#have"
p4 changes -m1 "path"#have
p4 changes -m1 "path"
I did add '...' with the path
result latest cl on perforce server
I expect last synced cl of directory
These commands are giving me desired result for files but not for directories.
Do:
p4 changes -m1 path/...#have
Note that to join the file specifier (which needs the ... to match files in a directory path) and revision specifier they need to be part of the same argument -- if there's a space between them on the command line they'll be interpreted as two different arguments (so you'll get the union of changes for the path at #head and the revision specifier #have across all paths).
If path contains spaces, quotes (which keep the shell from splitting the path into multiple arguments before passing it to p4) go around the entire argument:
p4 changes -m1 "path with spaces/...#have"
Related
I think the command is p4 changes, but I can't figure out the syntax for what I want.
I tried with
p4 changes -u myusername #2021/09/08,2022/04/04 /path/to/directory
where the date interval and the user name seem to be honored, but the path is not, so I think I've misunderstood what the doc means by //depot/project/... in this example:
p4 changes -m 5 //depot/project/... Show the last five submitted, pending, or shelved changelists that include any file under the project directory.
I tried taking the path from the address bar in Perforce Helix P4V when I select the file in the depot.
The revision specifier modifies the file path and they go together as a single argument:
p4 changes -u myusername /path/to/directory/...#2021/09/08,2022/04/04
See p4 help changes and p4 help revisions.
A lot of commands like p4 changes take a file[revRange] argument; in the above example /path/to/directory/... is file and #2021/09/08,2022/04/04 is revRange.
If you specify a revRange on its own then file is implicitly //..., which is why the first version of the command you tried returned results across the entire depot. The /path/to/directory was interpreted as a separate argument; if you left off the trailing ... wildcard it wouldn't match any files, so that part of the result was just empty.
Is it possible to get an fstat (or any other command) to return a list of all "existing" files (nothing thats been deleted/archived/etc) that dont exist on the users current workspace?
ideally, examples would be in python but standard p4 commands are fine too.
Assuming you mean files that were previously synced but have since been removed from the workspace, the standard command for this is p4 diff -sd:
diff -- Display diff of client file with depot file
p4 diff [-d<flags> -f -m max -Od -s<flag> -t] [file[rev] ...]
...
The -s options lists the files that satisfy the following criteria:
...
-sd Unopened files that are missing on the client.
You can also use p4 reconcile -n -d, p4 status -d, etc.
If you're simply looking for files that haven't been synced, that's just p4 sync -n. Files listed as added are those that are completely missing from the workspace and would hence be added to it by a sync.
I want to list the changes that have committed changes to certain depot paths
p4 changes //depot/path/blah/...
will not properly restrict changes to those that occurred on the given depot path but will in fact list changes made on a work space with a view path was equal to, or a superset of that path, regardless of whether any of the actual files changed were in the interested path.
e.g. changes made in a workspace containing a view on one of these paths:
//depot/path/blah/...
//depot/path/...
//depot/...
(possibly also requiring that a file was committed on one of those paths, I haven't tested that additional requirement)
creating a view on //depot/... may be daft, but if someone has done that, then their changes on //depot/OTHER-PATH/... will be fetched by
p4 changes //depot/path/blah/...
How can I restrict p4 changes to those changes that actually committed a file to the specified path?
I can read the entire output of p4 changes and run:
p4 files #=${change} | grep '^(...)'
where ... is a regex to match all of the depot paths I passed to p4 changes, to detect if any of the files were actually in the relevant depot path
but it seems very expensive to have to double-check all output, surely perforce can filter or check the output of p4 changes ?
For interest here is the full BASH snippet that works, $# is a list of depot paths (but without proper input sanity checking on $#):
ifs_join() { echo "$*" ; }
p4 changes -s submitted -i "$#" |
while read _1 change _rest ; do
p4 files #=$change 2>&- |
egrep "^($(IFS='|' ifs_join "${#%%...}"))" >/dev/null && echo "$_1 $change $_rest"
done
Each time we do a build, we have to record the changelist number of source files for tracking. We have different projects (under different directories) and they are synced at different changelist number. May you please show me how can we get the changelist number of a specific directory?
Also, there's p4 changes -m1 //path/to/your/project/...#have which, if run in the client workspace that synced the files for building, will give you the highest changelist number of the files in the workspace.
You can also use the short version p4 changes -m1 #have if you don't want to specify the directory.
If you are using a shell for which "#" is a comment character like bash, remember to escape it as follows: p4 changes -m1 \#have
p4 cstat //path/to/your/project...#have |grep -B1 have|tail -n2
#thegeko, this does not require high max_scanrows perforce limits
If your build system always syncs to head on the directory before building, you can use p4 changes -m 1 //path/to/your/project/... to get the head changelist number for that directory.
If you go with this method, I would suggest running the changes command before syncing, and then explicitly syncing to that changelist. That should eliminate the chance of someone checking in between the changes command and the sync command.
I use the "lazy manual way" (aka I don't know better) within the P4V client:
Use this in the "Submitted" tab filters: //yourproject/...#>have
And it will show you which CLs you haven't synched, note the oldest one.
Remove the #>have filter and see what's the CL that came before the one you just noted.
From within the directory:
p4 changes -m1 //...#have
Using just the workspace path, p4 changes -m1 /path/to/your/workspace/...#have (or cd /path/to/your/workspace; p4 changes -m1 $(pwd)/...#have) gives you the highest changelist number of the files in the workspace. This is similar to the accepted answer above from user1054341 p4 changes -m1 //your-client-name...#have, but you don't have to remember the client name.
A path to a subdirectory in the client gives you the latest changelist in that subdirectory and its children, e.g. p4 changes -m1 /path/to/your/workspace/src/module1/...#have. This can be run from any directory within the workspace.
Omitting #have shows the latest changelist checked in to the depot.
These commands must be run from a directory in the workspace.
In my case, I just want to know what changelist number is opened (not syned to) in a specific directory. For that, I do:
p4 opened -s | cut -d' ' -f5 | uniq
I am trying to get the last checkin on a particular folder structure on perforce, I know "p4 changes -m1 'filepath" does the job, but the problem is the filepath has to be the depot file-path. What I have on the other hand is the local filepath something like "C:\Android\Version10.2\MyApp\" and not "//depot/Andoid/Version10.2/MyApp".
I tried using commands like "p4 fstat", "p4 where" and "p4 files", but for all of them it works fine with the depot file path, if I give the local file path, it keeps complaining file(s) not on client/no such file(s).
The other issue is I dont have rights to change the p4client on the machine. How do I get this to work?
Basic question then to sum up is being able to get the last change on a folder/file for which I have the local filepath.
Regards
If you're going to run any commands on files those files have to be in the workspace. The problem is probably that p4 on Windows defaults to the machine name as the workspace name if you don't supply one.
So you either have to run set P4CLIENT=<clientname> then run p4 changes -m1 <filename>,
or p4 -c <clientname> changes -m1 <filepath> where <filepath> can be the file on your local file system, so C:\Android\Version10.2\MyApp\ would be acceptable.
Does p4 filelog -m 1 <filename> give you what you want? You can add the -l (lowercase L, not one) switch to get more information.
If you have a local file (as opposed to the depot-path), then you also should have a client-spec. You need to specify this with the -c option:
p4 -c <name-of-client-spec> changes -m1 <filepath>