Perforce Operations Manual

15 min read
On this page

Workspace mappings, the server have list, and local file contents can disagree. Confirm P4PORT, P4USER and P4CLIENT before syncing, opening changes, shelving or submitting. Replace example paths and changelist numbers.

TaskStart here
Files appear in the wrong placeMapping and have list
Offline edits are missingOpen and submit changes
Hand off unfinished workShelve and restore

Inspect mappings before forcing a sync

Verify server, identity, and workspace

# Identify the connected server, user, and client
p4 info

Check Server address, User name, Client name, and Client root. Resolve connection/authentication failures before sync.

# Check current login-ticket status
p4 login -s

If expired, log in interactively with p4 login and recheck. Do not put passwords in command arguments. Inspect p4 set separately for configuration sources.

# Read client Root, View, or Stream mappings
p4 client -o

This is read-only. Before editing with p4 client, save the specification and identify existing local work.

# Compare depot, client, and local paths
p4 where //depot/project/file.txt

Use an actual depot file. Not in client view indicates a mapping problem; forced sync cannot correct View.

# Read the server’s recorded synced revisions
p4 have //depot/project/...

... recurses over this scope; have does not verify disk content.

Preview the same scope before syncing

# Preview local additions, updates, and removals
p4 sync -n //depot/project/...

Check count, paths, and target revisions; preserve needed local edits before proceeding.

# Sync the reviewed scope to current depot revisions
p4 sync //depot/project/...

Pin a revision with @CHANGE or #REV on the same file spec and preview that spec first. Check output and have afterward; opened-file or clobber errors may leave partial results.

p4 where compares depot, client and local paths. Wrong Root, View or Stream leads to the wrong location. The client name is a logical workspace name, not necessarily the hostname. have records synced revisions; it does not verify current file bytes.

Preparing the visual
The have list is not the file bytes

sync -k updates server records without changing file bytes. sync -f transfers again; #none removes the controlled local file and its have entry.

OperationLocal filesHave list
p4 sync PATHUpdates revisions subject to opened-file and clobber rulesUpdated
p4 sync -f PATHForces transfer; protect local edits firstUpdated
p4 sync -k PATHNo transfer or file changeUpdates records only, like flush; can create inconsistency
p4 sync "//depot/project/...#none"Removes controlled local files in scope, subject to opened-file rulesClears corresponding records

"#none" is not metadata-only; quoting also protects shell metacharacters. Preview the same range with sync -n. A forced sync does not fix a wrong mapping.

Open files, then review the changelist

Choose an opening action for the change

edit/add/delete/move target different changes; they are alternatives, not a script to execute in full. Paths are relative to the verified workspace.

# Open a tracked file for editing
p4 edit file.txt

Edit the file, then inspect p4 diff file.txt.

# Open an existing new file for addition
p4 add new-file.txt

This does not create its contents; check the add action with p4 opened.

# Open an obsolete file for deletion
p4 delete obsolete-file.txt

This affects the local file and removes it from the depot head on submit. Verify the target with opened; review revert behavior before undoing a mistaken selection.

# Record a rename with history linkage
p4 move old-name.txt new-name.txt

Open the source for edit as required and use an unused destination. Verify paired move/delete and move/add actions and inspect the new path.

Discover offline edits before recording them

# Preview unrecorded changes beneath the current directory
p4 reconcile -n ...

Review add/edit/delete candidates and exclude generated files before scoped p4 reconcile path/to/file. Use p4 diff -f file.txt for unopened edits; this -f is not forced sync.

# Create a numbered changelist with a task description
p4 change

Edit Description and Files, save, and record the returned number. Replace example 12345 below with it.

Arbitrary file writes do not automatically enter a changelist. Preview offline add/edit/delete changes with reconcile -n, then reconcile a reviewed scope. Use diff -f for unopened files. Create a numbered changelist and reopen selected opened files into it.

Organize the list, resolve, then submit

# Move an opened file into the intended pending list
p4 reopen -c 12345 file.txt

-c selects the changelist; it does not open arbitrary unopened files.

# Inspect paths, actions, and file types in the list
p4 opened -c 12345

Review file contents with p4 diff -du file.txt; inspect added files directly. The describe -s summary is not a patch review.

# Preview unresolved work in this changelist
p4 resolve -n -c 12345

If needed, run p4 resolve -c 12345 and review each prompt, then inspect diffs, test, and preview again. Do not blindly accept one side.

# Submit the reviewed and tested resolved list
p4 submit -c 12345

Record the submitted change number and inspect p4 describe -s NUMBER. On failure inspect errors and opened state instead of assuming submission occurred.

Review before discarding local edits

# Preview the open action to be reverted
p4 revert -n file.txt

Save needed content before p4 revert file.txt. Edited content is discarded; add/delete actions have different local effects. For unchanged files choose revert -a with a reviewed scope and preview.

12345 is an example pending changelist. Review resolve candidates and each conflict, then verify contents, tests and target stream. revert discards opened-file changes; revert -a targets eligible unchanged files and still deserves review.

Shelves hold unsubmitted content on the server

Shelve and verify the server copy

# Save pending content as a server shelf
p4 shelve -c 12345

Use an existing pending changelist number. Shelving neither submits nor clears local work.

# Inspect shelved files and patches
p4 describe -S 12345

The recipient can locate it with p4 changes -s shelved -u YOUR_USER, using the verified owner name.

Restore into a new list in the receiving workspace

Verify recipient mapping/local work and create target 12346 with p4 change; source 12345 is a different number.

# Restore the source shelf into the target pending list
p4 unshelve -s 12345 -c 12346

Check opened -c 12346, diffs, and resolve -n -c 12346, then resolve/test as needed. The source shelf remains; cross-stream use needs mapping review.

# Delete the source shelf only after handoff and retention review
p4 shelve -d -c 12345

This neither reverts local work nor deletes submitted history. Recheck the number and content with describe -S before deletion.

Query history, line attribution, or stream specifications

# Inspect revisions and integration history
p4 filelog file.txt

Use p4 annotate file.txt separately for line attribution, then inspect the relevant changelist. These queries do not modify files.

# Read the stream parent and path rules
p4 stream -o //streams/main

Use the actual stream name and compare with the client specification’s Stream field.

Shelving neither submits to the depot nor clears local edits. Unshelve populates the destination changelist and may require resolve. Coordinate replacement of existing shelves. Deleting a shelf and reverting local work are distinct; review mapping and integration history across streams.

p4 sync · p4 reconcile · p4 shelve