I need to change filetype to add write permission (+w) to a lot of files under a root folder. I found the following command to remove +w; somebody knows how to change it to add +w instead of remove it?
Thanks in advance
p4 -F "%type%#%depotFile%" files ... | grep -e ".*w.*#.*" | sed -e "s/\(.*\)w\(.*\)#\(.*\)/edit -t \1\2 \"\3\"/" | p4 -x - run
No need for fancy grep/sed shenanigans when you're adding a modifier, since you can specify it directly to p4 edit -t:
p4 edit -t +w ...
Note that there's a reason the writable bit isn't set by default on files under Perforce control -- it makes it really easy to lose work by forgetting to open files for edit! I usually recommend only doing this for generated files where the cost of forgetting to check them in is low relative to the minor annoyance of having to remember to open them for edit before you compile.
Related
I'm currently (and regularly) performing very large integrations (usually 50k+ files). In P4V, it is technically possible to display and manually work with those files, but it's slow and unwieldy.
Is there some way to move unresolved files to a separate CL without needing to write an application? I was taking a look at "p4 resolve -n" but I can't figure out how to use that output with p4 reopen (assuming this is even the best way of doing what I want.)
Any help would be appreciated.
You can use this:
p4 -F %localPath% resolve -n | p4 -x - reopen -c default
Explanation:
-F %localPath%: tells p4 to output paths in local format
resolve -n: means "list unresolved files without actually resolving them". (P4 Resolve)
-x -: Tells p4 we'll be working on a list of files, and '-' means that the list of files is coming from stdin (piped) (p4 Global options)
reopen -c default: reopen incoming specified files in given changelist ("default" can be replaced by an existing changelist number). (p4 reopen)
Update:
For very big changelists, sometimes the command gets stuck. You can do it in 2 steps to workaround the problem:
p4 -F %localPath% resolve –n > c:\p4_output.txt 2>c:\p4_errors.txt
p4 -x - reopen -c default < c:\p4_output.txt
Note: When reopening files that were moved, p4 reopen will only move "half" of the change (the add) and leave the delete in the previous changelist. I haven't found a solution other than moving those manually.
Something like:
p4 -F %localFile% resolve -n | p4 -x - reopen -c CHANGE
ought to do it. (Run "p4 -e resolve -n" to see the list of available variables in the output, I think localFile is the one you want.)
I had a similar problem sometime ago.
To move a Perforce changelist to another computer/workspace,
follow the steps given in the below link:
movng unresolved files/changelists
I have created this code which will allow user to change the port in a specific file,
#Change Port
IRSSIPORT1=`head -n 1 /etc/ports.txt | tail -n 1`
sudo perl -pi -e "s/^$IRSSIPORT1.*\n$//g" /etc/ports.txt
sudo perl -pi -e "s/web_port = 8081/web_port = $IRSSIPORT1/g" .sickbread/config.ini
echo "sickbread Port: $IRSSIPORT1" | sudo tee -a $HOME/private/SBinfo.txt
What this code do is it takes a number from a file and then put it in the config file where it is required to change and deletes that number from the initial file from where it took it, but it requires read access as well as write access,
I tried everything in my knowledge to get it work without sudo, but i failed to do it.
Any suggestion?
I get this error -
Can't remove /etc/ports.txt: Permission denied, skipping file.
You can't do inplace edit on 666 files inside /etc as -i switch makes new file and deletes old one inside directory.
Since users don't have sufficient permissions to add/delete files from /etc (nor it would be good idea to do so), you have to read all file content at once, change it, and write back to the same file. Using a temporary file is also a workable solution.
While it may seem that the question is more about system administration rather than about programming, it's actually somewhat about perl so it's may be a good place for it here.
Doing chmod 666 /etc/ports.txt grants all users read-write access to this particular file (of course you don't need to put 777 as it's not an executable or script). So anyone will be able to open this file for writing and put any contents in it.
But when you do perl -pi -e ... /etc/ports.txt you don't only write into that file. Instead, perl will want to delete and then recreate this file, as shown here in strace output:
# strace perl -pi -e 's/a/b/' /etc/ports.txt 2>&1 | grep /etc/ports.txt
...
open("/etc/ports.txt", O_RDONLY) = 3
unlink("/etc/ports.txt") = 0
open("/etc/ports.txt", O_WRONLY|O_CREAT|O_EXCL, 0600) = 4
To delete the file it will need to have a write access not to the file itself, but to the directory /etc, which of course you cannot give to any user.
So I suppose you just don't need to try using in-place edit as it's always related to removing or renaming files, but instead get the contents of the file, make required changes and then write it back to the same file.
How to change perforce specs from command line?
What I want to do is, I have a workspace whose clobber option is set to noclobber (default value). Now I want to change it to clobber.
I know I can do it directly from p4v, but I don't want that. I also know that if I run p4 client, it will open P4CONFIG file in text editor, where I can change noclobber to clobber and save the file and it's done, but I also don't want that.
Please tell me the specific command which directly changes noclobber to clobber without using p4v or without editing P4CONFIG.
If you're trying to avoid repeatedly opening a text editor, you can accomplish your goal with a little bit of sed, like this:
p4 client -o | \
sed 's/ noclobber/ clobber/' | \
p4 client -i
It's pretty easy to script this with Perl, Python, Ruby, or even Powershell. Here's a one-liner in Powershell:
p4 client -o | %{$_ -replace "noclobber", "clobber"} | p4 client -i
Simplest solution:
P4EDITOR='sed -i s/noclobber/clobber/' p4 client
Not sure if this is possible or not, but I figured I'd ask to see if anyone knows. Is it possible to find a file containing a string in a Perforce repository? Specifically, is it possible to do so without syncing the entire repository to a local directory first? (It's quite large - I don't think I'd have room even if I deleted lots of stuff - that's what the archive servers are for anyhow.)
There's any number of tools that can search through files in a local directory (I personally use Agent Ransack, but it's just one of many), but these will not search a remote Perforce directory, unless there's some (preferably free) tool I'm not aware of that has this capability, or maybe some hidden feature within Perforce itself?
p4 grep is your friend. From the perforce blog
'p4 grep' allows users to use simple file searches as well as regular
expressions to search through file contents of head as well as earlier
revisions of files stored on the server. While not every single option
of a standard grep is supported, the most important options are
available. Here is the syntax of the command according to 'p4 help
grep':
p4 grep [ -a -i -n -v -A after -B before -C context -l -L -t -s -F -G ] -e pattern file[revRange]...
See also, the manual page.
Update: Note that there is a limitation on the number of files that Perforce will search in a single p4 grep command. Presumably this is to help keep the load on the server down. This manifests as an error:
Grep revision limit exceeded (over 10000).
If you have sufficient perforce permissions, you can use p4 configure to increase the dm.grep.maxrevs setting from this default of 10K to something larger. e.g. to set to 1 million:
p4 configure set dm.grep.maxrevs=1M
If you do not have permission to change this, you can work around it by splitting the p4 grep up into multiple commands over the subdirectories. You may have need to split further into sub-subdirectories etc depending on your depot structure.
For example, this command can be used at a bash shell to search each subdirectory of //depot/trunk one at a time. Makes use of the p4 dirs command to obtain the list of subdirectories from the server.
for dir in $(p4 dirs //depot/trunk/*); do
p4 grep -s -i -e the_search_string $dir/...
done
Actually, solved this one myself. p4 grep indeed does the trick. Doc here. You have to carefully narrow it down before it'll work properly - on our server at least you have to get it down to < 10000 files. I also had to redirect the output to a file instead of printing it out in the console, adding > output.txt, because there's a limit of 4096 chars per line in the console and the file paths are quite long.
It's not something you can do with the standard perforce tools. One helpful command might be p4 print but it's not really faster than syncing I would think.
This is a big if but if you have access to the server you can run agent ransack on the perforce directory. Perforce stores all versioned files on disk, it's only the metadata that's in a database.
For example, I have 100s of files checked out in a changelist:
//Development/MyProject/Version1.0/Coord/File1.cs
//Development/MyProject/Version1.0/Coord/File2.cs
...
//Development/MyProject/Version1.0/Coord/Filen.cs
//Development/MyProject/Version1.0/Common/File1.cs
...
//Development/MyProject/Version1.0/Common/Filen.cs
Similarly in some more directories. Now I want to checkout similar files in Version2.0
//Development/MyProject/Version2.0/Coord/File1.cs
//Development/MyProject/Version2.0/Coord/File2.cs
...
//Development/MyProject/Version2.0/Coord/Filen.cs
//Development/MyProject/Version2.0/Common/File1.cs
...
//Development/MyProject/Version2.0/Common/Filen.cs
I can do this by looking at what files have been checked out in Version1.0 and go to each directory in Version2.0 and checkout those files. This is tedious job.
Any aboveboard way of doing this?
From the linux/Unix/macOS shell, I suggest the following method. It would be significantly different in Windows unless you had unix tools installed there.
Check out all your Version1.0 files.
cd to your Version1.0 directory
Run the following command line:
p4 opened ... | sed 's/\#[1-9].*$//' | sed 's/\/Version1.0\//\/Version2.0\//' |
p4 -x - edit
Note: this would need some tweaking if any of your files have '#' symbols in their names. It's a quick-and-dirty fix. And credit to Bryan Pendleton above, who basically said the same thing much more briefly.