How to Use `p4 duplicate` for a Perforce Branch Path Rename (Deep Rename)

If you need to change a depot branch path in Perforce (Helix Core) without losing history, p4 duplicate is the command designed for that job. This guide is for DevOps and SCM engineers who need a practical, low-surprise workflow for a rename-style move (often called a deep rename) and safe cleanup afterward.

Originally published on 2012-05-16; fully revised and updated.

What p4 duplicate solves

The original problem was: can a branch name/path be effectively renamed, similar to directory rename? The practical solution is to duplicate revisions from the old depot path to a new one, then optionally remove the old path.

Per the command help text cited in the original post, p4 duplicate mirrors source revisions into target revisions “as if they always existed,” including metadata and contents.

• Duplicates revision content from source path to target path.
• Mirrors changelist number, date, attributes, and contents (as described in the original help excerpt).
• Duplicates integration records as well.
• Requires target revisions not to already exist.
• Requires target files not to be opened on any client.

Deep-rename workflow

flowchart TD
    A[Identify old depot path] --> B[Choose new depot path]
    B --> C[Run p4 duplicate]
    C --> D[Validate files and history]
    D --> E{Keep old path?}
    E -- Yes --> F[Leave source path in place]
    E -- No --> G[Run p4 obliterate -y on old path]
    G --> H[Update team configs and automation]

Command sequence

1) Duplicate old branch path to new branch path

p4 duplicate //depot/Jam/MAINds/... //depot/Jam/MAIN/...Code language: JavaScript (javascript)

This is the core rename-style step. Make sure the target path does not already contain the revisions you are creating, and that target files are not opened on any client.

2) Validate the duplicated path

p4 files //depot/Jam/MAIN/...
p4 filelog //depot/Jam/MAIN/...Code language: JavaScript (javascript)

Check that files are present at the new path and that expected history/integration lineage appears.

3) Remove the old path only if it is no longer needed

p4 obliterate -y //depot/Jam/MAINds/...Code language: JavaScript (javascript)

Warning: obliterate is destructive. Use it only when your retention policy, backup posture, and team process allow permanent removal.

4) Inspect built-in help for your server/client version

p4 help duplicate

Command comparison for rename-style branch moves

References

Original attribution: Perforce Support and community discussion thread:

http://maillist.perforce.com/pipermail/perforce-user/2010-November/027364.html

Best practices

• Run the duplicate operation in a controlled window to avoid active opens on target files.
• Validate with p4 files and p4 filelog before deleting anything.
• Treat p4 obliterate -y as a governed operation with explicit approval.
• Update workspace views, CI jobs, and documentation to the new depot path immediately after cutover.

Rajesh Kumar

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.