Perforce: how can I rename a directory name - version-control

My p4 stream is //ui/main and I have many files under //ui/main/src/. How can I rename src to be something else like apps?
I tried
p4 edit src/
I got this error:
src - files(s) not on client
The following doesn't work either:
p4 move src/... apps/...
I am using Linux so I am seeking a commandline solution. Thanks!

p4 edit src/...
p4 move src/... apps/...
Note that your stream needs to have apps/... in it! E.g. this will work fine for any path you want to put in this stream:
Stream: //ui/main
Paths:
share ...
but if your stream looks like this:
Stream: //ui/main
Paths:
share src/...
then the apps/... path doesn't exist in your stream and you won't be able to move things into it. (To fix this, add apps/... to your Paths before you do the move.)

Related

How do Perforce streams handle subpaths with different access than parent path?

For configuration of streams in Perforce, there exist five access types (according to documentation, in order more-to-less-inclusive): share, isolate, import/import+, exclude. They are placed in the configuration line-by-line, like so:
share folder1/...
isolate folder2/...
Is it possible to override the access to a subfolder? Like so:
share folder/...
isolate folder/subfolder1/...
In the way that, folder/subfolder1/... will be isolate-d, but folder/subfolder2/... and all others will be share-d? It seems like a lot of manual work to include all separate subfolders otherwise, especially if they are added as development progresses.
If this works, what are the rules? Do later lines override earlier lines?
Or do more restrictive access lines override less restrictive ones (i.e. can share parent folder, isolate child folder, but not other way around)? E.g. is something like
exclude folder/...
share folder/subfolder1/...
also possible?
Let's try it out. If I change my stream Paths to:
Paths:
share folder/...
isolate folder/subfolder1/...
here's what I get when I try to merge a path that's inside the isolated folder and outside it:
C:\Perforce\test>p4 merge -n folder/subfolder1/...
folder/subfolder1/... - no target file(s) in branch view.
C:\Perforce\test>p4 merge -n folder/subfolder2/...
No such file(s).
which tells me that, indeed, subfolder1 is isolated correctly. The "no target files in branch view" error tells me that the path is excluded from the branch view (which is the function of isolate), whereas "no such file(s)" lets me know that the only reason there's nothing to merge is that I didn't bother to actually add any files there.
Let's try the other example and see how that works. After changing my Paths to:
Paths:
exclude folder/...
share folder/subfolder1/...
I can do a similar experiment with p4 sync:
C:\Perforce\test>p4 sync -n folder/subfolder1/...
folder/subfolder1/... - no such file(s).
C:\Perforce\test>p4 sync -n folder/subfolder2/...
folder/subfolder2/... - file(s) not in client view.
and that also works as I'd expect (basically the same way classic client views work) -- the later and more specific line overrides the earlier and more general line, so subfolder1 is shared while subfolder2 is excluded.

Using p4 zip and unzip to export files from one perforce server to another

I was trying to export files along with their revision history inside my depot folder from 2015.2 to 2019 perforce server.Also , I would want perforce to create new user on my new server corresponding to the commiter/submitter on my original 2015 repo.
Perforce replicate looked like overkill for my current task and then I came across this read on perforce's website that mentioned P4 zip.
This looked like it will solve my problem, but the article has a few issues I could not understand.
Let's say I am moving data from server1_ip:port --> server2_ip:port
I am currently following these steps
Making zip of folder to be copied using
p4 remote my_remote_spec , setting
Address: server1_ip:port
DepotMap://depot/... //depot2/...
p4 -p server1_ip:port zip -o test.zip -r my_remote_spec -A //depot/.... But on this step I get permission denied error. This is weird to me because the user although not super/admin has access to files i ask to get zipped.
Also, when i did try with a super user, i could not find test.zip even though i was not prompted any errors.
Isn't the above command supposed to generate a zip file inside the directory which i run it from?
Is the unzip command supposed to be run after a p4 login from user of second server?
Lastly, from the document why is a third port , 1667 mentioned in the transfer of files from server running on 1666 and 1777.
on this step I get permission denied error. This is weird to me because the user although not super/admin has access to files i ask to get zipped.
This is expected:
C:\Perforce\test>p4 help zip
zip -- Package a set of files and their history for use by p4 unzip
...
The zip command requires super permission granted by p4 protect.
Isn't the above command supposed to generate a zip file inside the directory which i run it from?
Similar to p4 admin checkpoint, the zip file is written to the server machine (relative to the server root, if you don't specify an absolute path), rather than being transferred to the local client directory. This is not explicitly stated in the documentation (which seems like an oversight), but if you look in the root directory of the server where you ran the zip, you should find your test.zip there.
Is the unzip command supposed to be run after a p4 login from user of second server?
Yes, any time you run a command against a particular server, you will need to be logged in to that server. In the case of p4 unzip you will need at least admin permission on the second server.
Lastly, from the document why is a third port , 1667 mentioned in the transfer of files from server running on 1666 and 1777.
I'm pretty sure that's a typo; whoever wrote the article started off using ports 1666 and 1777, changed their mind halfway through, and didn't proofread. :)

CODEOWNERS in Github doesn't work as expected

Issue: CODEOWNERS need fully qualified path for rule against a directory/subdirectory.
I am writing a sample CODEOWNERS below to show the problem.
* #global-owner
foo/bar/ #octocat
I am expecting that whenever a PR is raised for any file (even recursively) inside directory foo/bar, user should be assigned a review. However, this always defaults to the * rule.
However, when I change the file to something like this:
* #global-owner
/app/src/main/java/com/cueo/foo/bar/ #octocat
This works like a charm. But the problem with this is that I need to repeat each directory twice to something like this:
/app/src/main/java/com/cueo/foo/bar/ #octocat
/app/src/test/java/com/cueo/foo/bar/ #octocat
According to the documentation:
# In this example, #octocat owns any file in an apps directory
# anywhere in your repository.
apps/ #octocat
I believe this should work for a nested directory structure also, like:
foo/bar/apps/ #octocat
We need to prefix the paths with ** as well. This is not clear from the documentation.
So if we add a rule like:
* #global-owner
**/foo/bar/ #octocat
#octocat will be assigned for all foo/bar directories in the project.

Zip files with encryption in a remote share, keeping orignal names and location

My team faces the need to encrypt all files in a repository with AES256. For this purpose, we decided we are going to zip all files with such encryption, using the same key for all of them.
The problem we have is that these files sit in a NAS, so from windows boxes they are accessible by \ to them.
The directory structure is something like this:
Original Structure:
Root
-1
|--folder1
|---file1.ext
|---file2.ext
|--folder2
|---filea.ext
|---fileb.ext
|--folder2.a
|---filec.ext
and so on...
Essentially, what we need is to have all the original files contained in a zip file, keeping their original names, which would be something like this:
Desired Outcome:
|-Root
|-1
|--folder1
|---file1.zip
|---file2.zip
|--folder2
|---filea.zip
|---fileb.zip
|--folder2a
|---filec.zip
and so on...
To accomplish this, we tried a batch script that calls 7zip, but it only works if it's run from the root directory, which is something we cannot use as the files are not in a server.
Here is the syntax of the batch script we came up with:
FOR /R %%i IN ("*.wmv") DO "C:\Program Files\7-Zip\7z.exe" a -mx0 -tzip -pPasswordHere "%%~dpni.zip" "%%i"
But, as wrote previously, it only works when run from the root folder, which is something we cannot do as files sit on a network location.
Mapping the drive or making a symbolic link to it doesn't do the trick either.
I've also checked on 7zip to do this, namely, making use of its "-r" operator, but I couldn't find a way to get the desired outcome (namely, recurse through all folders in the remote tree structure -there are a lot of them...- and keep the original file name).
I'm open to any suggestions as any kind of script, trick or guizmo that gets the job done will be more than welcome. =)
Thanks a million in advance!,
Sebas.
----SOLUTION----
I actually found a sollution here, mapping the drive in a different way (it's so simple it just made me feel stupid(er), but it's altogheter beautiful).
Using the batch script below, the remote share can be mapped like so:
You can map a drive using
net use X: \\server\directory
and then you can change to that directory using
pushd X:
(Post from which the answer was taken from: Batch File Iterating through files on a local network server)

How to copy a file from source to a destination and recreate the folder structure

I have some files which needs to be copied through deployment process often to a destination. This is my folder folder structure:
SOURCE:
c:\
folder1
sub1
subsub1
file1
file2
I need something where i can tell my "script" something like this
mycopy c:\folder1\sub1\subsub1\file1 h:\
That means that i dont want to
check if folder structure exist
provide on bot sides the complete structure for each file on destination side
I want to
provide the full path and filename on source side
create folder structure if not exist
overwrite file if exist
How can i achieve this?
See the robocopy help page on MS Technet
https://technet.microsoft.com/en-us/library/cc733145%28v=ws.11%29.aspx
In your case you would do something like
robocopy c:\folder1\sub1\subsub1 h:\ file1 <options ...>
Notice that the first two parameters are the source and dest paths only, with no filename at the end
Read the linked help page and test on your desktop ...
Ok it works like this:
You can use Robocopy for this task. Thanks you Rick716 for this direction. I am not marking it as answer cause it is only a direction not the solution.
Lets Assume that we have the following source folder structure:
N:\source\a1\b1\c1\d1\e1\f1
and we want to recreate the hole structure under n:\source within h:\destination. Then we have to use Robocopy in this way:
robocopy N:\source h:\destination /e
The option /e will create the folder structure even create empty folders. Additionally you can append the files which should be copied. For example
file.txt
*.jpg
*.bkp
etc. But these files will be even copied when they exist somewhere within the folder strcuture! For example you have the file n:\source\a1\file.txt and the file n:\source\a1\b1\c1\file.txt then both will be copied by using
robocopy N:\source h:\destination file.txt /e