Use of p4 duplicate command | P4 Command Guide


Use of p4 duplicate command

Problem Area is –
Is there any possibility to rename branch name? as directory rename is possible?

Solution is – p4 duplicate command

What the command ‘p4 duplicate’ was implement to do was create a duplicated revision of a folder as if it always existed. This is explained in the ‘p4 help duplicate’, I have copied below:

Duplicate revisions as if they always existed.  All aspects of
   the source revisions are mirrored into the target revisions,
   including changelist number, date, attributes, and contents.
   The target revision must not already exist, and the target file
must not be opened (for any operation) on any client.

Integration records are duplicated as well.

To rename branch names is possible with the process of a deep rename operation.

p4 duplicate //depot/Jam/MAINds/… //depot/Jam/MAIN/…

The above command will create an exact copy of the branch you’re duplicating including its integration history.

Then the duplication source is not wanted anymore, so you will need to use the obliterate command:

p4 obliterate -y //depot/Jam/MAINds/…

You can find more information about “p4 duplicate” by running the “p4 help duplicate” command.

If you have any further questions please let me know.

Reference –

Perforce Support and

Tagged : / / / / / / / / / / / / / /

Perforce Slow Sync issues | Perforce Slow Sync Troubleshooting Guide


Perforce Slow Sync issues

Network latency
Sync Performance issues are not obvious with locally connected hosts, as the network latency is low. However, as latency increases, performance worsens.

To correct the issue, follow these steps on the client machines exhibiting the issue:

Network problems:
How do I determine if slow Perforce response time is caused by network problems?

A network issue can be suspected if Perforce commands run quickly on the local machine but run slowly across a network. You can also compare the lapse time against the usage time, for example, if the information is available in the Perforce logs.

Any of the following can cause slow responses:

  1. Misconfigured domain name server (DNS)
  2. Misconfigured Windows name server (WINS) or Windows domain
  3. Slow network response

1. p4 info

A good initial test is to run the p4 info command. If this command does not respond nearly immediately then there is a network related problem.
The p4 info command uses the P4PORT setting to contact the Perforce Server. If the P4PORT setting uses the hostname of the server machine, a DNS lookup is required to fetch the server IP address. If the DNS server is failing or the network is slow, the lookup process takes time. You can use the IP address directly to avoid the DNS lookup.

2. Hostname vs. IP Address
On a client machine, try using the Perforce Server’s IP address in the P4PORT setting. This avoids the DNS lookup used to convert the hostname to an IP address. Here is a P4PORT example which uses the server hostname:

Using the IP address directly, the P4PORT setting then looks like this:


If you do not have the Perforce Server machine’s IP address handy, you can use the ping command to find it. Here is an example of how you would run the ping command:

3. ping hostnam

The output of the ping command lists the IP address for the hostname.

If the p4 info command responds immediately when you use the IP address in the P4PORT setting, you have a misconfigured DNS.

“p4 info” vs. P4Win

The p4 info command is processed by the Perforce Server. As the Perforce Server compiles the output information for the command, it does a reverse DNS lookup on the client’s IP address. A forward DNS lookup might be fast, while a reverse DNS lookup is slow. One way to determine if a reverse DNS lookup is slow is by using P4Win, the Perforce Visual Client. The “Show Connection Info” operation in P4Win does not perform a reverse DNS lookup.

You can compare the response of P4Win’s “Show Connection Info” with the response from the command line p4 info. If a “Show Connection Info” operation is fast while a p4 info is slow, there is a reverse DNS lookup problem on the Perforce Server machine.

4. The “hosts” file

To work around DNS problems, add hostname IP address entries to the hosts file. This task is typically performed by a Systems Administrator; be sure to follow your company’s standard procedures.

Rather than using an IP address for the P4PORT setting, you can add a hostname IP address entry in your hosts file. The host file can be tricky to find. Here are a few places it can be:

Windows Server 2000 (and later):




The following is an example entry for the hosts file: hostname

If you have determined there is a reverse DNS problem, you need to add an entry for your client hostname in the machine’s hosts file where the Perforce Server resides.

5. Wildcards on Windows

In some cases, p4 commands using unquoted file patterns with a combination of depot syntax or client syntax and wildcards can cause delays.

p4 files //depot/*

p4 files //client/*

The delay occurs because the wild card expansion routines for Windows mistakes the depot name or client name for a network system name. You can prevent the delay by putting double quotes around the file pattern:

p4 files “//depot/*”

Network Topology

Most networks use 100 Mbit technology. The maximum theoretical transfer rate of this type of network is 10 Mbytes per second. In most cases slower transfer rates are experienced. If a network is saturated, transfer rates can drop off significantly, maybe as low as 4 Mbytes per second. In cases of network saturation use of network routers or switches can help.

6. Client on a Network Filesystem

It is possible that the p4 executable itself is on a networked file system that is performing very poorly. To check for slow access to the executable, try running:

p4 -v

The p4 -v command simply prints out the version information and does not attempt to access the network. If you get a slow response, network access to the p4 executable itself may be the problem. Try copying or downloading the p4 executable onto a local filesystem.

7. Server on a Network Filesystem

Using a network filesystem for the Perforce Server must be thought through very carefully. Just as in the scenario above with the Perforce client stored on a network filesystem, data to and from the server application must go through the network twice. The Perforce Server also uses file locking on vital data files. Not all network filesystems have efficient locking implementations and some are buggy.

If the network is saturated and the transfer rate is down to about 4 Mbytes per second, the Perforce Server cannot satisfy client requests. Each client request uses part of the network, and the Perforce Server must share that resource in order to access the network filesystem. A cheap hard drive these days will provide a 20 Mbyte per second transfer rate. A good SCSI hard drive can transfer as much as 160 Mbytes per second. If possible, try to avoid a network filesystem related server bottle neck.

Try and play with “p4 ping” by progressively increasing the message count, receive and transmit lengths (one at a time). If you hit the same wall repeatedly, then this could very well be indicative of some throttling taking place somewhere

8. p4 -z tag info

9. Reference.

Tagged : / / / / / / / / / / / / / /

“Cheat Sheet” of Perforce command-line | Perforce command-line Guide


A way to remember data-mining commands
The following is a set of questions that will be used during the Perforce training to remind students which “data-mining” commands to use for specific situations. Perforce is a terrific tool, but it’s easy to get lost in the choices between “p4 files” and “p4 changes” and “p4 filelog” and so on. This list can help a great deal.

the question starts with…
the answer starts with…
“What are the filenames that…?” “p4 files….” p4 files //depot/…#have
p4 have
p4 files //depot/…
(which is the same as)
p4 files //depot/…#head
p4 files //depot/…@label
p4 files //depot/…@client
p4 files //depot/…@2001/02/12
p4 files //depot/…@1541
“What are the differences between the
workspace copy of XXX and the depot
copy of XXX?”
“p4 diff …” • p4 diff file.c
• p4 diff file.c#2
• p4 diff file.c#head
• p4 diff //… or “p4 diff”
• p4 diff –se
“What are the differences the depot copy
of ______ and the depot copy of ______?”
“p4 diff2 ….” • p4 diff2 file1.c file2.c
• p4 diff2 file1.c#1 file.c#2
• p4 diff2 dir1/… dir2/…
• p4 diff2 dir1/…@now dir1/…@2000/01/02
“Tell me everything about changelist #___.” “p4 describe” • p4 describe 1231
“What’s a list of changelists that….?” “p4 changes….” • p4 changes
(which is the same as)
p4 changes //…
• p4 changes file.c
• p4 changes –i file.c | grep 1255
• p4 changes //depot/…@label1,@label2


“Cheat Sheet” of Perforce command-line
The following list is a set of helpful commands that anyone can run, but that the person administering the Perforce codelines will
be using a lot. They’re included here for quick reference.

Create a new workspace…
1. That’s modeled after the
“1.0dev” workspace – same
2. That’s the Perforce defaults,
Set the workspace name using “p4 set” or in the environment. Then run:
1. p4 client –t 1.0dev
2. p4 client
Retrieve a file as of
1. Now (head revision)
2. April 15, 2000
3. Label “xyz”
4. Changelist 123456
5. the revision that client
“” has retrieved
6. The revision you had before
accidently bashing your disk
Use “p4 sync” as follows:
1. p4 sync
p4 sync
p4 sync
2. p4 sync
3. p4 sync
4. p4 sync
5. p4 sync
6. p4 sync –f
See “p4 help revisions” for more examples. Note that anywhere that “” is used in these
examples, a full pathname (“c:\work\projects\”) or depot name
(“//depot/rel_218/base/projects/”) could be used.
Open a file for:
1. add
2. edit
3. delete
And then publish the change to others
Use “p4” with the appropriate verb:
• p4 add
• p4 edit
• p4 delete
Then “p4 submit” to publish it
What have I changed in the files I
have opened for edit?
• p4 diff (for all opened files)
• p4 diff file1 file2 (for specific files)
Undo a checkout. If the file hasn’t been submitted yet:
• Use “p4 revert –a” to find all opened files that have no modifications – it’ll revert those.
• Use “p4 revert” to revert an individual file.
• Use “p4 revert //…” to revert all files.
Remember that “p4 revert” is irreversible.
If the file has been submitted, you’ll need to open the file for edit and check in a prior revision.
Use very good change descriptions to say what you did and why.
Interrupt your work to edit a single
file and check it in, without any other
disruptions. (You’re hacking Java and
someone needs a “relnotes.txt”
updated ASAP to issue a release.)
Two ways:
1. Edit the file and submit only that file.
• p4 edit relnotes.txt
• do the modifications
• p4 submit relnotes.txt
2. Make a new changelist to manage just that change.
• p4 change
remove all the files in this change from the Files: section, it’ll create an empty
• p4 edit –c XXX relnotes.txt
where XXX is the change number in the previous step
• p4 submit –c XXX
Publish your work to others “p4 submit”
Compress the data on the net
because you have a slow modem line
between your workspace and the
Run “p4 client” for your workspace, and change the options from “nocompress” to “compress”.
(Read “p4 help client” for details.)
Get the list of…
1. All changelists applied to the
base codeline
2. … to the prodxyz codeline
3. … to the prodxyz codeline,
including those applied
originally to another codeline
and integrated into prodxyz
4. All revisions of
Use “p4 changes” or “p4 filelog” as follows:
1. p4 changes //depot/eng/…
2. p4 changes //depot/eng/prodxyz/…
3. p4 changes –i //depot/eng/prodxyz/…
4. p4 filelog
Push … from the base codeline
(“prodxyz”) to the 1.0.1 codeline
1. Push change #1232
2. From change #129 to #134
3. all changes in the base
Use “p4 integrate –b prodxyz-1.0.1” as the place to start, in each case:
1. p4 integ –b prodxyz-1.0.1 //…@=1232
2. p4 integ –b prodxyz-1.0.1 //…@129,@134
3. p4 integ –b prodxyz-1.0.1 (no additional args)
Note that this assumes that the named branch specification “prodxyz-1.0.1” has been created
by your project lead or administrator using “p4 branch”.
Push … from the prodxyz-1.0.1
codeline to the base (“prodxyz”)
1. Push change #1235
2. From change #127 to #128
3. all changes in the base
Use “p4 integrate –b prodxyz-1.0.1” as the place to start, in each case:
1. p4 integ –b prodxyz-1.0.1 –r @=1235
2. p4 integ –b prodxyz-1.0.1 –r //…@127,@128
3. p4 integ –b prodxyz-1.0.1 –r (no additional args)
The “-r” reverses the order of source/target in that named branch specification.
Note that for the ‘selective integration’ cases, you’ll want to be VERY CAUTIOUS of ‘accept
Show the ‘diff’ between the
prodxyz-1.0.1 codeline and its
“p4 diff2 –b prodxyz-1.0.1” (This works because “prodxyz” is the name of the branch
specification, not because “prodxyz” is part of “//depot/prodxyz/…”)
What branches do I have? If you use “p4 branch” to create branch specifications and use them consistently, then “p4
branches” provides this info.
How do I make a new codeline
named prodxyz-2.0?
There are several steps:
1. Make a named branch specification. Save it.
• “p4 prodxyz-2.0”
• if you want to exactly imitate another branch (e.g. prodxyz), use
“p4 branch –o prodxyz-1.0.1 > tmp” to capture the output, edit this temporary file
and replace the “1.0.1” references with “2.0”, then run “p4 branch –i < tmp”.
2. Run the “p4 integrate” command to populate this new codeline. Submit the change.
• p4 integrate –b prodxyz-2.0
or, if you want to push content as of a certain label (e.g. “xyz”) from the parent,
p4 integrate –b prodxyz-2.0 //…@xyz
• p4 submit
3. Send e-mail telling everyone about this codeline and what it’s used for.
Put everything onto a laptop, you’re
going to the beach and want to hack.
(This assumes that you won’t be
connected to a net while away.)
There are several steps:
1. Connect the laptop to the net.
2. Run “p4 sync” to populate the source onto the laptop.
3. Leave for the beach.
4. While editing, use “chmod” or “attrib” to make the files writeable. Make your changes.
5. Get back to work, reconnect to the net.
6. Run the following commands to tell you what’s updated and open them for
• p4 diff –se | p4 –x – edit
• p4 diff –sd | p4 –x – delete
• find . –type f –print | p4 –x – add
Then inspect what’s opened (“p4 opened”) and what you’ve changed (“p4 diff”). Submit or
revert as appropriate.
Run a checkpoint “p4 admin checkpoint” – only an administrator can run this. (An administrator has “super”
permissions in the “p4 protect” data.)
Be sure to back up the checkpoint, the current journal, and each of the “depot” directories on
the server machine!
Change the security/permissions “p4 protect” – only an administrator can run this.
“p4 protects” – used in 2006.1 and later to TELL you your permissions .
Make a label It’s a two-step process:
1. Make the label using “p4 label xxx”
2. Populate it using “p4 labelsync –l xxx”
or if you have a specific list of files,
“p4 labelsync –l xxx file1 file2 …”.
Copy a label’s contents to another
label. Assume that the existing label
is “xxx” and the new label is to be
Again, a two-step process:
1. Make the label using “p4 label –t xxx abc”
2. Populate it using
“p4 labelsync –l abc //…@xxx”
Note that the second step is really identical to the second step in the previous question – we’re
just specifying a very specific list of revisions [of files] to include in the new label.
In 2005.1 and later, “p4 tag” will make the label and apply it to a set of files.)


Tagged : / / / / / / / / / / / / / / / / / /

Command Line to find a Change list properties in perforce server


Command Line to find a Change list properties and associated path of the file in perforce server view:

Examples of the command you want:
p4 describe 1231928
p4 describe -s 1231928
p4 files @=1231928

Where 1231928 is the change list number.

Tagged : / / / / / / / / / / / / /

Step by step guide on PerforceDFiles Tool | Perforce Tutorial


This tool can be used to add thousands of files and directory in perforce server on single click which is having different-different hierarchy

Java should install and class path should set.

Put the code under ClientSpec root folder in the same hierarchy which you want to add in perforce server.

Create a changelist first. Just go to command prompt and type “p4 change”. Perforce will automatically create a changelist and will give you the changelist number. It will also ask you to update a text file with the changelist description. Just give the appropriate description there. Note the changelist number.


The file file has one file called “”. So first update it with two values. The changelist number and the source path. The source path can be “D:/Perforce/Components/DatabaseServer”.
Use forward slash only “/”.

Step4: Once these files are updated, you can run the script file “makescript.bat” which will update the “checkinscripts.bat” with new checkin scripts.

Step5: Run “checkinscripts.bat” and refresh perforce console. See that new folder is created below components folder and the files are inside

Note: The file which will not be added into perforce server can be found in “missedfiles.log”



Tagged : / / / / / / / / / / /