There are three major approaches to moving the versioned depot files under P4ROOT:
- Use the server.depot.root configurable (introduced in 2014.1)
- Modify the depot Map: path
- Use symlinks to modify one or more depot paths
Use the server.depot.root configurable
A server.depot.root configurable was introduced in Perforce Server version 2014.1. From 'p4 help configurables':
server.depot.root Base directory of depots with relative maps
This configurable can be used to change the default location of Perforce depots directories (the directory tree where versioned files are stored on the server). For example:
p4 configure set server.depot.root=D:\P4ROOT2\
This configurable only applies to relative depot Map: fields. Absolute paths in the depot Map: field are unaffected by the server.depot.root path.
- Your backup process must take the server.depot.root location into account (and not assume depot files exist in the default P4ROOT location).
- The new configurable takes affect immediately; new files submitted after the configurable is set will be written to the new server.depot.root location.
- Best practice is to move depot files from the old P4ROOT location to the new server.depot.root location to simplify the backup process.
Modify the depot Map: path
The filesystem path where a depot's versioned files are stored is specified by the "Map" field in that depot's specification.
An example of a default Depot specification:
# A Perforce Depot Specification.
# Depot: The name of the depot.
# Owner: The user who created this depot.
# Date: The date this specification was last modified.
# Description: A short description of the depot (optional).
# Type: Whether the depot is 'local', 'remote', or 'spec'.
# Address: Connection address (remote depots only).
# Suffix: Suffix for all saved specs (spec depot only).
# Map: Path translation information (must have ... in it).
# Use 'p4 help depot' to see more about depot forms.
Date: 2002/10/17 12:10:51
Created by michael.
By default, the depot directory location is given as a path relative to the P4ROOT
directory and is named the same as the depot itself, however, this location can be changed and mapped to either a different path relative to P4ROOT, or to an absolute path outside of P4ROOT.
To change your depot directory:
- Backup all your depot directories.
- To prevent users from accessing the depots while you are moving them, you can set protections to prevent write access by entering the command:
Add the following mappings at the end of the Protections field:
list user * * -//...
super user <username> * //...
An alternative is to set the server to localhost mode by setting P4PORT to localhost:port_number, and then restart the Perforce server. This will prevent any connections from hosts other than the Perforce server, effectively locking everyone out of the machine.
Note: The localhost mode requires either direct access to the Perforce server hardware, or access using a remote desktop or SSH.
- Get a list of all your existing depots:
p4 -ztag depots
- For each depot reported, the map field gives you the current location of the depot directory.
- Copy each depot directory from its existing location to its new location.
: This is typically the longest operation, which could significantly increase down-time. Using a synchronizing utility like rsync -avz (under most Unix based systems) or xcopy or Robocopy (for Windows) can reduce the impact of this step. They allow you to copy the bulk of the versioned files in advance, and then incrementally update at the time you change the Map. See Moving a Perforce Server
for xcopy and rsync flags.
- Update the map field of each depot specification by running the command:
p4 depot <depot_name>
And replace the value of the Map field <depot_name>/... by <path>/<depot_name>/...
(where <path> is the full path of the new location where the <depot_name> directory is located). For example, you can change
Note: If the Perforce server is being run under a WIndows OS, you will need to include the drive letter as a part of the path. The path should always end in with a forward or backslash (/) and the Perforce ellipses wildcard (...).
- Run the command:
p4 verify -q //...
If you immediately see "MISSING" errors, there is likely a problem with the path. This is most commonly a typo in the Map field, or a typo in the path itself.
Note: The verify command can be safely cancelled with control-C.
- Either remove the mapping protections added previously:
Or, switch P4PORT back to the original setting and restart Perforce.
It is possible to use symlinks to move the storage location of one or more depot paths. Whereas the first two suggestions above rely on native Perforce Server functionality, use of symlinks introduces Operating System specific functionality that is independent of Perforce -- and must be accounted for outside of Perforce.
Symlinks can be used to move the entire depot location, or just a subdirectory. For example, you might have one particular depot or depot subdirectory with a terabyte of large files that needs to be stored on a different volume.
Some words of caution. Because symlinks for depot storage location are not tracked by the Perforce Server and are subject to being moved, deleted, modified, or forgotten about by system administrators, Perforce does not recommend using them as a general solution.
Symlinks are supported on both Unix and later versions of Windows. The behavior of symlinks in your environment should be transparent to the Perforce Server, compatible with your backup tools, and documented by your Perforce system administrator. Failure to account for any of these items could lead to loss of server data.
If you are using 'tiny.db' to store some of the smaller (tiny) file revisions, you will need to take further steps to ensure the 'move' is completed successfully. The tiny.db. file itself is stored in the P4ROOT folder, but the full path to the the file revision is stored inside 'tiny.db', using the directory structure present prior to changes to the depot spec's 'map' field or 'server.depot.root'. You will need to take a checkpoint of 'tiny.db', correct the content, and restore using this manually-updated tiny.db checkpoint.
Please contact support for assistance with this process.