p4 paths import are not coming to workspace - perforce

If I type
p4 stream -o -v //path/to/My/stream
I could see the following items in Paths
Paths:
share ...
import+ Foo/proto/... //Depo1Path/api/api_main/...
import+ Bar/proto/... //Depo2Path/SomeProjectname/proto/...
When I create a workspace with Helix Visual Client (P4V) of //path/to/My/stream both Foo/proto/ and Bar/proto/ are coming properly. But when I create workspace with p4 command from shell script, Foo/proto/ and Bar/proto/ are not coming to the workspace.
My script is given below
export P4CLIENT=$workspaceName
mkdir -p ${checkoutDir}
cd ${checkoutDir}
p4 client -i <<HERE
Client: ${P4CLIENT}
Owner: ${P4USER}
Root: ${checkoutDir}
Options: noallwrite noclobber nocompress unlocked nomodtime normdir
View:
${depotPath} //${P4CLIENT}/...
HERE
p4 sync -f
Can anybody point out what I'm doing wrong?

If you want a Stream client you must specify the Stream field and omit the View field.
Assuming "depotPath" is your stream:
p4 client -i <<HERE
Client: ${P4CLIENT}
Owner: ${P4USER}
Root: ${checkoutDir}
Options: noallwrite noclobber nocompress unlocked nomodtime normdir
Stream: ${depotPath}
HERE

Related

Perforce revert operation gives client unknown. Create it with p4 client command

I have already created a perforce client with command:
p4 client -o -e <my_clientname>
and it gave a message created with the required user.
but while using this clientname for revert operation with command
p4 -c <my_clientname> revert <perforce_path...>
it gives me an error "Client <my_clientname> unknown - use 'client' command to create it."
Additional Info: I am working on a jenkins setup with Perforce plugin.
p4 client -o does not create your client; it simply prints out to stdout the form specification that you could have used to create your client.
To create your client, do:
`p4 client -o <my-client-name> | p4 client -i`
By the way, in your question, you wrote that you also passed the -e flag. I don't believe there is a -e flag to p4 client.

How to delete a pending changelist in Perforce from an old workspace and offline machine (by admin access)

Note: I want to delete the changelist only not the client.
The answers in the following link doesn't work when the pending changelist is from an old workspace which is in an offline machine Perforce: How can I delete a changelist that p4v refuses to delete?
Tried the following command p4 -u <user> -c <client> -H <host> revert -k <file(s)>
But I'm not allowed to do as the workspace owner is different.
First get the USER and CLIENT:
p4 describe CHANGE
With a 2015.1+ server at this point you can just do:
p4 revert -c CHANGE -C CLIENT //...
p4 change -df CHANGE
With an older server it's a few more steps.
First get the HOST so you can bypass the hostname check:
p4 client -o CLIENT
Now login, revert the files, and delete the change:
p4 login USER
p4 -u USER -c CLIENT -H HOST revert -k -c CHANGE //...
p4 change -df CHANGE

Perforce sync files in remote workspace

How do I sync a file at a remote location?
I am submitting a file at a certain workspace and need that file to be synced to its latest revision in a workspace that is at a remote system?
I can obviously have scheduled task on the remote machine that syncs the file in the required workspace but I wanted to check if a simpler solution is available?
I have not tried it myself but it seems the p4 sync command takes some
global options.
So you could probably have a single master sync script calling :
p4 -c <clientA> -H <remote hostA> sync #...
p4 -c <clientB> -H <remote hostB> sync #...
p4 -c <clientC> -H <remote hostC> sync #...

Perforce - unshelve files into another directory

I have two directories into the same workspace, I shelved some files into a changelist in the first directory and now I want to unshelve them into the second.. I tried this command:
p4 -c my_workspace unshelve -s 17654070 -n -b //my_workspace/directory2
Branch '//my_workspace/directory2'
unknown - use 'branch' command to create it.
How can I have this working?
You'll need to create a branch spec to tell the server the relationship between the two directories.
run p4 branch some_branch_name
In the view field put:
//depot/directory1/... //depot/directory2/...
Save the form and run p4 -c my_workspace unshelve -s 17654070 -n -b some_branch_name

Revert File not in a workspace in perforce

I am trying to delete an old user from our perforce installation. A previous admin had deleted all their active workspaces / clients so we should be able to now delete the user, however when i run
p4 user -f -d auser
User auser has file(s) open on 1 client(s) and can't be deleted.
However auser no longer has any associated clients, and if I filter the pending changelist view in P4V it shows the user as having one file checked out in the default changelist but no client is specified. Even if I log in as the user I dont seem to be able to revert or do anything with the file. Any hints how I might solve this?
While both of these commands returned nothing:
$ p4 clients -u <USER>
$ p4 changes -s pending -u <USER>
This command showed me which file was open:
$ p4 opened -u <USER>
//depot/path/to/file#1 - edit default change (text) by <USER>#<CLIENT>
This command doesn't work:
$ p4 -u <USER> -H <CLIENT> revert -k //depot/path/to/file
//depot/path/to/file#1 - belongs to user <USER>, not reverted
Deleting the client does:
$ p4 client -o <CLIENT> > <CLIENT>.txt
$ p4 client -d -f <CLIENT>
$ p4 opened -u <USER>
File(s) not opened anywhere.
FTW! \o/
If you need to, you can then recreate the client with:
$ p4 client
Then read in the <CLIENT>.txt file you created with the output of p4 client -o <CLIENT> and save it.
More here:
http://answers.perforce.com/articles/KB_Article/Reverting-Another-User-s-Files
Solved.
A bit weird but this is what I did. I got the details of the default changelist that contained the file. It had the workspace name which was the name of a machine. I logged into the machine and then into perforce as the user. At this point I could see the pending changelist and revert the file. Now I can delete the user.
How did this happen?
I think what must of happened was a confusion of clients. A while back I changed the owner of quite a few clients on that machine (its the build server) and some of these clients must have had open files for the old user. This is the only explanation I can come up with.

Resources