This can be done like this:
1. p4 delete dir,
p4 submit;
2. p4 add dir/file,
p4 submit;
Is there a way to do this in one go?
I don't want to do p4 submit in step 1 because not having that directory will break things at my end.
There does not seem to be anything preventing this:
C:\Perforce\test\dir>p4 opened
//stream/main/dir#1 - delete default change (symlink)
//stream/main/dir/bar#1 - add default change (text)
//stream/main/dir/foo#1 - add default change (text)
C:\Perforce\test\dir>p4 submit -d "presto"
Submitting change 106.
Locking 3 files ...
delete //stream/main/dir#2
add //stream/main/dir/bar#1
add //stream/main/dir/foo#1
Change 106 submitted.
Related
I have a project like:
/a
/a/one/src/...
/a/one/target/...
/a/second/src/...
/a/second/target/...
/a/third/one/target/...
....
/a/million/staff/other/target/xxx.class
I need to make p4 status to ignore all target subfolders:
cd a
p4 status
<do not output anything is */target/*>
cd one
p4 status
<do not output anything is */target/*>
Within p4 ignore documents looks like it's all about single folder, that is not my case
Add target/ to your P4IGNORE file.
C:\test>p4 status
dir\target\foo - reconcile to add //stream/main/dir/target/foo#1
dir1\target\bar - reconcile to add //stream/main/dir1/target/bar#1
C:\test>echo "target/" >> p4ignore.txt
C:\test>p4 status
No file(s) to reconcile.
If you need something a little stronger than P4IGNORE (e.g. you want to exclude target/ folders that other people have already added to the depot), you can exclude these folders from your client view like this:
View:
//depot/... //client/...
-//depot/.../target/... //client/.../target/...
I have a build folder in perforce that keep tracks of all my builds but the files inside it have different revision numbers (because they are / are not affected from different builds), so in the same folder i have files with revision #1200 and other with revision #2000.
I initially was thinking to obliterate the old revisions from p4admin, since there is the option "obliterate up to revision", but in the case of this folder I'm not sure how this will behave.
There is any way in p4 for keeping only the last 2 revision of all the files in that folder? Or the only doable way is writing a script for checking each file's revision before obliterating it?
Perforce doesn't have an additive relative revision syntax, unfortunately, so you can't use #head-2 or anything like that.
The easiest way to do something like this IMO is to create a label with the #head-2 revisions, which you can do iteratively using the #< relative revision specifier on the label itself:
# start by labeling #head
C:\Perforce\test>p4 tag -l minus2 ...#head
//stream/main/0.f1#3 - added
//stream/main/1.15#4 - added
//stream/main/1.16#1 - added
//stream/main/1.17#1 - added
//stream/main/1.18#2 - added
//stream/main/2.f1#5 - added
//stream/main/2.f2#4 - added
# now replace everything in the label with the previous revision
C:\Perforce\test>p4 labelsync -l minus2 "...#<minus2"
//stream/main/0.f1#2 - updated
//stream/main/1.15#3 - updated
//stream/main/1.16#1 - deleted
//stream/main/1.17#1 - deleted
//stream/main/1.18#1 - updated
//stream/main/2.f1#4 - updated
//stream/main/2.f2#3 - updated
# now do it again, bringing us to #head-2
C:\Perforce\test>p4 labelsync -l minus2 "...#<minus2"
//stream/main/0.f1#1 - updated
//stream/main/1.15#2 - updated
//stream/main/1.18#1 - deleted
//stream/main/2.f1#3 - updated
//stream/main/2.f2#2 - updated
Now the label has all the latest revisions that I want to obliterate. I'll double-check with p4 files -a before doing p4 obliterate:
C:\Perforce\test>p4 files -a #1,#minus2
//stream/main/0.f1#1 - add change 72 (text)
//stream/main/1.15#2 - edit change 77 (text)
//stream/main/1.15#1 - branch change 73 (text)
//stream/main/2.f1#3 - integrate change 81 (text)
//stream/main/2.f1#2 - integrate change 78 (text)
//stream/main/2.f1#1 - branch change 74 (text)
//stream/main/2.f2#2 - integrate change 79 (text)
//stream/main/2.f2#1 - branch change 75 (text)
C:\Perforce\test>p4 obliterate -y #1,#minus2
//stream/main/0.f1#1 - purged
//stream/main/2.f1#2 - purged
//stream/main/2.f1#3 - purged
Deleted 4 label 24 integration 8 revision record(s).
As far as I can tell, my client is setup correctly:
$ p4 client -o
# A Perforce Client Specification.
# ...
Client: stephen-dev1-stephen
Update: 2014/06/26 17:41:14
Access: 2014/06/26 17:45:47
Owner: StephenRasku
Host: stephen-dev1
Description:
Created by StephenRasku.
Root: /home/stephen/Code
Options: noallwrite noclobber nocompress unlocked nomodtime rmdir
SubmitOptions: submitunchanged
LineEnd: local
View:
//depot/labs/products/component/SpamView-URI/... //stephen-dev1-stephen/SpamView-URI/...
//version/... //stephen-dev1-stephen/version/...
//thirdparty/... //stephen-dev1-stephen/thirdparty/...
//starteam/... //stephen-dev1-stephen/starteam/...
//specs/... //stephen-dev1-stephen/specs/...
//release/... //stephen-dev1-stephen/release/...
//projects/... //stephen-dev1-stephen/projects/...
//main/... //stephen-dev1-stephen/main/...
//features/... //stephen-dev1-stephen/features/...
//dev/... //stephen-dev1-stephen/dev/...
//depot/... //stephen-dev1-stephen/depot/...
The files exist:
$ pwd
/home/stephen/Code/SpamView-URI
$ ls mainline/EBUILD_VERSION mainline/package.sh mainline/ebuild
mainline/ebuild mainline/EBUILD_VERSION mainline/package.sh
But it complains when I try and add them:
$ p4 add mainline/EBUILD_VERSION mainline/package.sh mainline/ebuild
mainline/EBUILD_VERSION - file(s) not in client view.
mainline/package.sh - file(s) not in client view.
mainline/ebuild - file(s) not in client view.
What's the problem? I checked out the file using git p4 clone if that makes a difference.
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 you see an error attempting to add a file,
for example, you might want to check your mapping to confirm that the
file resides in a directory that is within your client view.
See the section under 'Client Workspace View':
http://answers.perforce.com/articles/KB_Article/Common-Permissions-and-File-Access-Problems
Are the files under this exact directory structure below?
/home/stephen/Code/SpamView-URI/mainline/EBUILD_VERSION
/home/stephen/Code/SpamView-URI/mainline/package.sh
/home/stephen/Code/SpamView-URI/mainline/ebuild
Judging by the first View mapping line of:
//depot/labs/products/component/SpamView-URI/... //stephen-dev1-stephen/SpamView-URI/...
I would guess that is the path they should be under.
If you 'cd' into the '/home/stephen/Code/SpamView-URI/mainline'
directory are you able to add these files?
Your client spec isn't right, as you noticed. With these 2 lines,
//depot/labs/products/component/SpamView-URI/... //stephen-dev1-stephen/SpamView-URI/...
//depot/... //stephen-dev1-stephen/depot/...
Your trying to map the files under //depot/labs/products/component/SpamView-URI/... to both //stephen-dev1-stephen/SpamView-URI/... and //stephen-dev1-stephen/depot/labs/products/component/SpamView-URI/... Since perforce reads top to bottom, it will overwrite your first mapping with the second mapping, basically removing the second mapping. \
Move your //depot/labs/products/component/SpamView-URI/... //stephen-dev1-stephen/SpamView-URI/... to the last line, and you should be ok.
How to grep/find for a particular text in all files within a pending changelist?
My use case:
I have a debug_flag in my code and would want to make sure I do not check-in any code with the debug_flag which will cause a compiler error for all others. (Not for me since I have the debug_flag declared locally)
p4 describe changelist# gives you the list of the files in a changelist, but it has some extra information, and the paths are with respect to the depo. Example:
p4 describe 12334
output:
Change 12334 by me on 2014/01/04 00:57:08 pending
Some test changelist
Affected files ...
... //depot/path/to/my/files/file1#15 edit
... //depot/path/to/my/files/file2#12 edit
With a few search/replace or a simple perls script, you can change this text output to a list of files with actual path and then run grep on them:
xargs grep "debug_flag" < file_list.txt
In perforce changelists get renumbered on submission. So for e.g. when the changelist was created it would be numbered 777 , but on submission of changelist it would get renumbered to say 790.
My question is how do I get the new CL number (790) , if I know the old CL number 777 , or vice versa ?
If you really want the original changelist number, that can be retrieved from Perforce without having to embed the original changelist number in the description. You can use the -ztag command line option to get at it. And you can only get at it through the 'changes' command (as far as I know):
d:\sandbox>p4 submit -c 24510
Submitting change 24510.
Locking 1 files ...
edit //depot/testfile.txt#2
Change 24510 renamed change 24512 and submitted.
d:\sandbox>p4 -ztag changes -m1 //depot/testfile.txt
... change 24512
... time 1294249178
... user test.user
... client client-test.user
... status submitted
... oldChange 24510
... desc <enter description here>
<saved
As pointed out, it's probably not that useful. However, I did want to note that it's possible to get at it.
The only way I can think of is adding the original changelist number as part of the changelist description field. First, you'll need a script to store the original changelist number:
#!/bin/env perl
$id = $ARGV[0];
open (CHANGE_IN, "p4 change -o $id|");
open (CHANGE_OUT, "|p4 change -i $id");
while (<CHANGE_IN>)
{
if (/^Description:/ and not /ORIGID/)
{
s/(^Description:)(.*)$/$1 ORIGID $id. $2/;
}
print CHANGE_OUT $_;
}
close (CHANGE_IN);
close (CHANGE_OUT);
Save this as origid.pl on the Perforce server with the executable bit set. Then setup a trigger with p4 triggers.
Triggers:
add_origid change-submit //depot/... /usr/bin/origid.pl %change%
Version 2012.1 of Perforce introduced the -O (capital oh) argument to p4 describe, which allows you to query a changelist by its original number (before being renumbered by p4 submit).
I find this very helpful, since I often find myself keeping notes about a changeset before it is submitted, then forgetting to note what it was renumbered to on submission.
So if I have a note talking about change 12300, I can now see what it refers to by typing:
p4 describe -s -O 12300
and having Perforce tell me:
Change 12345 by me#myhost on 2013/10/31 00:00:00
Fix that thing I wrote that note about
Affected files ...
... //Proj/MAIN/foo.c
The ztag method mentioned earlier can be used to find the old changelist number of a submitted change:
> p4 -ztag describe -s 12345 | grep oldChange
... oldChange 12300
Adding to Eric Miller's reply, because I can't comment (not enough points):
to just emit the 1 number
p4 -ztag describe $ORIG | sed -e 's/^\.\.\. oldChange //;t-ok;d;:-ok'
e.g.
OLD=$(p4 -ztag describe $ORIG | sed -e 's/^\.\.\. oldChange //;t-ok;d;:-ok')
or if you want to look up many numbers, this will output a map of new old on each line (may be useful with the "join" command). If there is no old commit, then it re-emits the new commit.
p4 -ztag describe 782546 782547 ... | sed -e '${x;p};s/^\.\.\. change //;t-keep;b-next;:-keep;x;/./p;g;G;s/\n/ /;x;d;:-next;s/^\.\.\. oldChange //;t-ok;d;:-ok;H;x;s/ .*\n/ /;x;d;'
I tried to avoid using GNU extensions to sed.
Unless you do something like Tim suggests the old change list number will be lost on submission.
Change list numbers are only temporary until you actually submit. So if you create a new change list (777 say) and then decide to delete it, the next change list you create will be 778.
It can be a bit more elegant if you use the P4 Python module.
i.e.
import P4
p4 = P4.P4()
p4.connect() # having a valid p4 workspace/connection is on you :)
c = p4.run_describe('969696') # describe a Submitted, renumbered changelist, i.e. 969696
old_pending_cl_number = c['oldChange'] # print out prior/pending CL# if this exists.
Cheers