Originally published on 2014-09-22; fully revised and updated.
This guide is for engineers preparing for Perforce (Helix Core) interviews or maintaining existing Perforce environments. It focuses on practical commands from the original post, clarifies where each command fits, and highlights safety considerations for admin operations.

Core Perforce commands interviewers often ask about
These are common command-level checks in interviews: file history inspection, changelist discovery, and status-based filtering.
# Show each line in a file with revision attribution
p4 annotate file.c
# Last 10 changelists touching a project path
p4 changes -m 10 //depot/project/...
# Last 10 changelists by status
p4 changes -m 10 -s submitted //depot/project/...
p4 changes -m 10 -s pending //depot/project/...
p4 changes -m 10 -s shelved //depot/project/...Code language: PHP (php)
| Command | Best for | Interview angle |
|---|---|---|
| p4 annotate | Line-by-line revision tracing | Debugging ownership and historical context |
| p4 changes -m N | Recent activity in a path | How to scope by depot path and limit result size |
| p4 changes -s status | Filtering by submitted/pending/shelved | Operational reporting by lifecycle state |
Ignoring files in a workspace: client view exclusions and P4IGNORE
The original post shows two ways to keep generated binaries (for example, .dll) out of normal reconcile/add flows: negative mappings in the client view and an ignore file via P4IGNORE.
# Example client view exclusions from the original article
-//depot/foo/*.dll //CLIENT/foo/*.dll
-//depot/foo/.../*.dll //CLIENT/foo/.../*.dllCode language: PHP (php)
The post also includes a compact variant:
-//depot/foo.../*.dll //CLIENT/foo.../*.dllCode language: JavaScript (javascript)
References from the original post: Stack Overflow discussion, exclude directories from Perforce commands, and the P4IGNORE command reference.
flowchart TD
A[Edit files locally] --> B[Run Reconcile Offline Work]
B --> C{Excluded by view or P4IGNORE}
C -- yes --> D[Shown as excluded files]
C -- no --> E[Opened for add or edit]
E --> F[Review changelist]
F --> G[Submit]
Admin commands and interview prompts for Perforce superusers
The p4 admin command family is used for service-level operations and is typically restricted to superusers.
p4 admin checkpoint [ -z | -Z ] [ prefix ]
p4 admin journal [ -z ] [ prefix ]
p4 admin stop
p4 admin restart
p4 admin updatespecdepot [ -a | -s type ]
p4 admin resetpassword -a | -u user
Reference: p4 admin command reference.
Common admin interview questions
- How do you take a Perforce backup?
- How do you restore a Perforce backup?
- How do you verify the health of repository metadata?
- What is the difference between
p4 dbverifyandp4 verify?
Choosing metadata mechanisms: counters, keys, attributes, properties
The original article distinguishes these mechanisms by simplicity, association with files, and visibility/control needs.
| Mechanism | Use when | Scope and behavior |
|---|---|---|
| p4 counter / p4 key | You need flat key/value storage | Simple storage; typically no rich visibility model |
| p4 attribute | Metadata is tied to files | Associated directly with file objects |
| p4 property | You need admin-managed definitions and controlled visibility/precedence | Used by Perforce applications such as P4V; not core server metadata behavior by itself |
p4 property -n name -v value
p4 counter mycounter 123
p4 key mykey 12
p4 attribute -n name -v value files...
Commands that can permanently remove file data
The original post explicitly warns that p4 archive -p is one of the few commands that removes file data, and names p4 obliterate as the other. Treat both as high-risk operations and validate policy before use.
| Command | Risk level | Operational guidance |
|---|---|---|
| p4 archive -p | High | Use with caution; confirm retention and recovery requirements first |
| p4 obliterate | High | Use only with explicit approval and change tracking |
Perforce integration topics often discussed in interviews
- Git Fusion
- Swarm
- Replication
For each integration topic, be prepared to explain why it is used, where it fits in your workflow, and the operational trade-offs.
Best practices
- Scope commands by depot path (
//depot/project/...) to reduce noise and risk. - Prefer explicit exclusion rules for build artifacts to keep reconcile output clean.
- Separate interview knowledge into user commands vs superuser/admin commands.
- Treat archive/obliterate workflows as controlled change events with approvals and backups.
- Validate command syntax against your installed Helix Core version before production use.
I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.
I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.
Find Trusted Cardiac Hospitals
Compare heart hospitals by city and services — all in one place.
Explore Hospitals