I have a list of ignore rules in a p4ignore.txt per http://www.perforce.com/perforce/doc.current/manuals/cmdref/env.P4IGNORE.html
I would like to list the files in my workspace matched by the ignore rules. How can I do that?
(In Git, this is easy https://stackoverflow.com/a/2196755/284795 )
As I understand p4 status lists files in the workspace that either
exists in the repository (depot) and differ from it
don't exist in the repository and aren't matched by the ignore rules
I would like to list files in the workspace that are matched by the ignore rules, whether they exist in the repo or not.
If p4 status is already returning no files, you can use p4 reconcile -I to see what would be added if the ignore rules aren't used.
If p4 status is returning files already, but you'd still like to see the difference, you can run it once with and once without -I and diff the two.
p4 reconcile -n ... > /tmp/foo
p4 reconcile -nI ... > /tmp/foo2
diff /tmp/foo /tmp/foo2
Related
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.
Due to legal issues, we had to obliterate entire projects from our Helix/Perforce repositories.
We were partially successful, all the past versions of the files are gone, the depots are gone too.
However, the workspaces and all the associated changelists are still there (P4V > View > Submitted Changelists).
The changelists correctly show that there are no files associated with them (because we obliterated them), but the changelist descriptions are still intact and we need those deleted as well (they contain legally "important" information, so we need them gone permanently, period).
Now my question -- is there a way either to:
1) obliterate workspaces and all the changelists pertaining to obliterated depots and workspaces?
2) If not, is there a way to script this so we can clear all descriptions of changelists under the obliterated depots/workspaces? There are thousands of changelists to modify so manual work is impossible.
Thank you very much.
Ok, I studied the Helix documentation and came up with a scripted solution. In case anyone has the same problem, I'm posting my steps to solve this below:
0) This requires all of the changelists you want to delete to have all files associated with the changelists to have been obliterated beforehand. If you haven't done that, use p4 obliterate to remove the files from the depots.
1) In command prompt with admin rights, run:
p4 changes -c the-name-of-your-workspace >c:\prune.bat
2) Open the file c:\prune.bat in a text editor that has regular expressions (regex).
3) Using regex, replace all occurrences of the string "Change " with "p4 change -f -d " (without double quotes, of course).
4) Replace all strings matching " on 2.*$" with an empty string (removes the remaining portion of the line until its end). Note: The number 2 in the search regex pattern matches the first digit of years 2000-2019 and beyond. If you have changes before the year 2000, use the digit 1.
5) Inspect your batch file, it should contain something like this:
p4 change -f -d 2083
p4 change -f -d 2074
p4 change -f -d 2073
p4 change -f -d 2072
p4 change -f -d 2071
6) Run your batch from the command prompt with admin rights.
Enjoy. Hope this helps.
Here's an easy one-line solution that works on any platform:
p4 -Ztag -F "change -df %change%" changes -c CLIENT | p4 -x - run
If the idea is to get rid of all changelists where the files have been obliterated (i.e. all empty changelists), then you can leave off the -c CLIENT. The change -df command will skip changes where the files haven't been obliterated, so it's fine to just run it over all changes.
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
One of our team member (located in different region) has shelved changes in P4 with changelist 1234.
Now, if I want to see what files are modified snf what are the changes, how can I do this?
What is the P4 command that I should use to see the changes made by our team member?
p4 describe -S 1234 should to the trick, see the documentation on describe.
To see the file content you would unshelve the files into your workspace (assuming you have a workspace for the same project your colleague is working on).
Create a new (empty) changelist with p4 change (results in e.g. 2345), then use p4 unshelve (docu) to get the modified files to your workspace:
p4 unshelve -s 1234 -c 2345
If you don't want the modified files in your workspace any longer, you can p4 revert -c 2345 them.
Using the GUI, go to Pending and remove all filters except by user, where you will put the other developer's ID. From there you should be able to see her Changelists, including the ones having shelved files. Right click on the Shelved Files icon and select Unshelve. You will have to have a workspace active that includes the files that you are trying to unshelve.
Using UI client, press Ctrl+G. Dialog window is appears. Select Changelist in combobox and input number of changelist.
Let's assume that changelist 123456 is the shelved changelist in question. As a previous answer mentioned, the way to list the files are associated with that changelist is via the p4 describe -s <changelist> command. Like so:
$ p4 describe -s 123456
Change 123456 by john.doe#JohnsBranch on 2013/10/24 15:38:10 *pending*
[Shelving my changes for Jane.]
Fix memory corruption caused by uninitialized pointer.
Affected files ...
... //depot/branches/JohnsBranch/kernel/vm/pageutils.c#1 edit
Once you know the file(s) in question, there are a couple of ways to diff the files without a corresponding workspace. Method #1 is to use p4 print:
$ p4 print -q //depot/branches/JohnsBranch/kernel/vm/pageutils.c#1 > /tmp/old
$ p4 print -q //depot/branches/JohnsBranch/kernel/vm/pageutils.c#=123456 > /tmp/new
$ diff /tmp/old /tmp/new # Or use kdiff3, tkdiff, etc.
...
<diff output here>
The other method is to use p4 diff2:
$ p4 diff2 //depot/branches/JohnsBranch/kernel/vm/pageutils.c#1 //depot/branches/JohnsBranch/kernel/vm/pageutils.c#=123456
...
<diff output here based on Perforce server's diff algorithm>
Both methods can be easily incorporated into the scripting language of choice.
jhwist's solution is good if you want to see the files' diffs.
If you want to see just the shelved files, use p4 describe -sS 1234.
The lower case s restricts the output from including file diffs.
If you wanted to see the actual content of the files, you could use:
p4 print <file>#=<shelved_change>
The #= means to look at the shelved change, where as # means to look at the change.
If you want to see only the list of files inside a ChangeList (whether it's a shelve, pending or submitted CL), without extra data, grep the result:
p4 describe -S 12345 | grep -oP '(?=//).*(?=#)'
In P4V UI, select
Search - > Go To
then choose type of changelist (in your case 'Pending changelist'), enter changelist number and click "OK".
You may try
p4 -ztag describe <changeno>
The description contains a string called '... shelved' if it is shelved.