P4 Server FAQ
If you see this error while running Pi commands, it may be because your Perforce administrator has configured the server to require a minimum client version.
IPLM ships with the Perforce API, which may be an older release than your current P4 client and server; generally this is not a problem as Perforce maintains API compatibility across releases, but if 'minClient' is set on your P4 server then Pi commands which rely on the P4 API may fail with the above message.
The fix is to remove 'minClient' with 'p4 configure' or set it to the current release of the P4 API (2016.2 as of Sept 2016)
Moving Perforce Data from one Server/Depot to Another Using 'p4 fetch'
Occasionally data needs to be copied with history from one Perforce server or Depot to another. This is easily accomplished via the 'p4 fetch' command.
Configuring the Perforce Servers to allow 'p4 fetch'
On the source server from which the data will be copied run the following p4 command:
> p4 configure set server.allowfetch=2
On the destination server set the value:
> p4 configure set server.allowfetch=1
This setting determines whether changes can be fetched:
- If set to
1
, this server can fetch from other servers. - If set to
2
, other servers can fetch from this server. - If set to
3
, both1
and2
are allowed.
Defining the 'remote' to tell p4 fetch which files to copy on the source server
> p4 remote import
Fill out the form that is brought up:
RemoteID: import Address: testserv2:1667 Owner: mdx Options: unlocked nocompress copyrcs Update: 2017/07/04 12:17:05 Access: 2017/07/04 12:20:32 Description: Created by mdx. LastFetch: 1 LastPush: default DepotMap: //mdx_test/import/... //mdx_test/tutorial/trc/
Where:
'Address' is the server name and port of the source depot and
'DepotMap' is the destination for the copied files in the destination depot (first argument) and source of the copied files in the source depot (second argument)
Fetching the data
Once the remote is configured you are ready to copy (fetch) the data from the source server using the remote definition you set up (called 'import' below'):
> p4 fetch -r import 1 change(s) containing a total of 177 file revision(s) were successfully fetched.
Once the fetch is complete the new files can be managed as usual.
References
Perforce IPLM ensures that a unique client name is used for each user workspace and cached IPV
User workspaces
Generated workspace client name
Default constructor
By default, Perforce IPLM will create a Perforce client for a new user workspace in the format:
ws:{user}:{lib_ip}:{wsid}
- user is the unix username
- lib_ip is library_name.ip_name of the top IP in the workspace
- wsid is the first eight characters of the workspace UUID
for example:
ws:fred:mylib.myip:34dscFjl
User-defined constructor
You can define your own client name constructor by setting client_format in the PWM section of piclient.conf using any combination of the above keywords. The constructor must include {wsid} to ensure that the client name is unique.
client_format example:
client_format = myproject:{user}:{wsid}
.IP Cache
A Perforce client is created for each IPV in the cache. The naming convention is:
share:<site>:[<project>:]<libname>:<ipname>:<line>:<release>
for example:
share:sanjose:mdxtest:mylib:myip:TRUNK:1
In a multisite installation using the IP Cache, <site> must be set so that the cache server will generate unique client names.
File locking over NFS is relatively slower than on local disks, in order to maximize performance it is best to host Perforce database, depot, and journal files on disks local to the Perforce server.
More information can be found in the Helix Core Server Administrator Guide - Planning the installation - Filesystem.
Often a remote IP workspace might require a refresh when any of its files change in a different workspace. This can be implemented by a Perforce trigger that updates the workspace (the updateshared.bash script below) when a Perforce submit occurs.
An example of the Perforce trigger is as follows:
sync_shared1 change-content //depot/path_to_files/... "updateshared.bash" %change%"
The following will sync the workspace to the state of the depot after Changelist 21 was submitted.
> p4 sync //depot/proj1/...@21
More information can be found in the Helix Core Command-Line (P4) Reference - p4 sync.
The following will sync the workspace to the state of the depot as of midnight, June 24, 2011.
> p4 sync @2011/06/24
More information can be found in the Helix Core Command-Line (P4) Reference - p4 sync.
Occasionally it is necessary to relocate the versioned files in a p4d server. The simplest method is to copy and link the depot subdirectory to the new location
- stop p4d daemon
- cp -a depot depot.bak
- cp -a depot to <new-location>
- ln -s <new-location>/depot
- start p4d daemon
This process can also be achieved using Perforce configurations. See Moving Depot Files To A Different Location.
Finally, a complete of a p4d server is a little more involved. See Moving a Perforce P4D Helix Core Server.
See the Perforce Knowledge Base article: Reverting Another User's Files
Use P4IGNORE to ignore file types. For more information, see Ignoring Files with P4IGNORE.
Perforce allows users to configure the batch size (number of arguments) when processing a command from a file using the `-x` argfile
option. The batch size can be set by using the '-b' global option (supplied on the command line before any Perforce command). By default, the batch size is 128.
Although the optimum batch size number varies according to the user environment, increasing the batch size above its default value improves performance up to 5x (for example `p4 sync` for large filelists).
To configure the batch size used by the Workspace Manager in Perforce IPLM, you have a few options.
- Configure p4_sync_batchsize in the piclient.conf file, see Client Configuration
- Set the environment variable MDX_PWM_P4_SYNC_BATCHSIZE (equivalent to #1 but via an environment variable)
- Add the Helix Core flag to the MDX_P4_CMD:
MDX_P4_CMD=p4 -b 1024 and the Workspace Manager will set the batch size to 1024 for Perforce operations.
Problem: If I restrict a user in the p4 protect table by IP address I get permission related errors when the user performs p4 actions. I do not get errors if I change the IP address to '*'.
Solution: This issue can arise if you are connecting to the perforce server through a proxy. In this case the IP address in the p4 protect table must be prepended with 'proxy-'
For further information, see Protections for Proxy Users.
This behavior can be modified by the dm.proxy.protects configurable.
Problem: How can I tell how long it takes for a file to get replicated in Perforce?
Solution: To track this on an ongoing basis the best approach is to pull the information out of the Perforce logs.
Structured logs may be the easiest to process, more on setting that up here:
Structured Server Logs (KB article)
Events show up in the log file:
18,1522083152,996817427,2018/03/26 09:52:32 996817427,2013,0,mdxservice,10.8.5.37,rmt-FileFetch,10.8.5.37,p4d,2017.2/LINUX26X86_64/1594901,,import,//mdx_test/tutorial/adc/TRUNK/hw_code/test/test.v,1.8,0
And can be formatted with the "p4 logparse" command:
... f_eventtype 18 ... f_timestamp 1522083152 ... f_timestamp2 996817427 ... f_date 2018/03/26 09:52:32 996817427 ... f_pid 2013 ... f_cmdno 0 ... f_user mdxservice ... f_client 10.8.5.37 ... f_func rmt-FileFetch ... f_host 10.8.5.37 ... f_prog p4d ... f_version 2017.2/LINUX26X86_64/1594901 ... f_args ... f_action import ... f_file //mdx_test/tutorial/adc/TRUNK/hw_code/test/test.v ... f_rev 1.8 ... f_filesize
Looking at log files on the commit & various edge servers can then be used to find the replication time between servers.
A log processing tool such as Splunk can then be used to process this data automatically.
The following link explains why you can't use p4 local syntax to obliterate on an edge: Edge Servers.
You need to use depot syntax to obliterate (as well as archive, attribute -f, labelsync, populate, restore, retype, snap and tag) against an edge server. These commands are run against the commit so they need to be run using depot syntax.
After changing the typemap on the p4d server, existing files on the server will need to be manually reset to match. This can be performed via the p4 retype command.
For example, if you want to enforce the binary+Fl typemap on all files recursively under the docs folders:
p4 retype -t binary+Fl //depot/.../docs/...
Or if you want to ensure that all the cadence .oa objects stored under the cds directories are type binary+Fl:
p4 retype -t "binary+Fl //.../cds/.../*.oa"
This is a server-side command. For more information about p4 types please see Helix Server File Types and p4 typemap.
Perforce is licensed on a per-commit server basis. Edge servers attached to a licensed commit server are not separately licensed.
The Perforce license file should be renamed to 'license.txt' and placed in the $P4ROOT directory. Please note the default P4ROOT path for a standard Perforce IPLM installation is :/usr/share/mdx/repos/p4. Then we can run the p4 license command to load:
$ p4 license -i < $P4ROOT/license.txt License file saved.
Note that loading a new Perforce license for the first time will require a p4d restart:
> service p4d restart Stopping Perforce: Starting Perforce:
The 'p4 info' command can be run against the server to verify that the license has been loaded. Typically the server will fail to start if there is a problem with the license. This can be debugged via the p4 log file. If loaded correctly there will be a line similar to this in the output of 'p4 info':
... Server license: MyCo Inc. 1500 users (support ends 2019/12/31) (expires 2019/12/31) ...
More details on Perforce licensing can be found here.
Perforce has a number of special characters that it uses in various ways:
Character
|
Reason
|
---|---|
@ | File revision specifier for date, label name, or changelist number |
# | File revision numbers |
* | Wildcard |
... | Wildcard (recursive) |
/ | Separator for pathname components |
More details on handling Perforce special characters can be found here.