Moving from Perforce

If your team runs Perforce (Helix Core) today, most of Swarmfile will feel familiar: changelists, exclusive checkouts of binary files, stream-style branches, review before a change lands. The big difference is that there's no workspace to sync. Your project is a mounted drive: files stream on demand, and a save is on its way to the team the moment you make it.

This page maps Perforce concepts onto Swarmfile, explains how to bring a depot across, and is direct about what doesn't carry over.

Concept map#

Bringing a depot across#

There's no Perforce history importer. Swarmfile can't read a Perforce server's revision history and replay it as commits. What you can bring across is the current state of a depot or stream, and that's usually what a team needs to start working.

1. Get the head revision on disk. In a Perforce workspace that maps the depot or stream you're moving, p4 sync to the revision you want to start from.

2. Create the Swarmfile project, and decide its branches (one per stream you're moving, usually starting with main).

3. Import with swarmfile-migrate. Dry-run first to check what would be imported and that your excludes are right:

   swarmfile-migrate --source /p4/workspaces/game-main \
     --org-id acme-games --project-id game \
     --exclude ".p4config" --exclude "**/.p4ignore" \
     --dry-run
   
   swarmfile-migrate --source /p4/workspaces/game-main \
     --org-id acme-games --project-id game \
     --exclude ".p4config" --exclude "**/.p4ignore" \
     --state-db ./migrate-state.db --verify --report-json ./migrate-report.json
   

   --state-db makes a large import resumable, --verify checks each file after upload, and --report-json gives you a record of everything that arrived. The swarmfile-migrate reference has every flag, and Migrating Existing Data walks through a full run.

4. Commit and tag the import (for example swarmfile tag create imported-from-p4) so there's a named starting point.

5. Recreate permissions and exclusive-checkout habits: ACLs for restricted folders, and checkout locks (or Windows worksharing) for the binary files your team used to +l.

6. Keep Perforce read-only for older history. Leave the server up in read-only mode (or archive it) for as long as you need to look up who changed what before the move. Swarmfile's history starts at the import.

Moving one stream at a time works fine; Swarmfile doesn't need to own the whole depot on day one.

Where it's genuinely different#

• No sync, no have-list. You never decide which revision your workspace holds; the drive shows the branch as it is. Large files you haven't opened take no disk space until you do. To keep a set of files local for the road, use Pack & Go.
• Saves are shared immediately by default. Perforce shares nothing until submit. Swarmfile's default mode lands each save as it's made; switch a project to staged mode, or open a changelist, when you want Perforce-style batching.
• History moves forward. Reverts, restores, and rollbacks are recorded as new commits rather than edits to old ones, and commit --amend changes only a message.
• Whole-file versions. Like Perforce for binaries, every version is a whole file (stored deduplicated, so unchanged parts of a large file cost nothing to keep).

What's not there yet#

• A Perforce history importer. Import the head revision as above and keep the old server for history.
• Game-engine source-control plugins. There's no Unreal Editor or Unity source-control provider for Swarmfile today, so the editors' built-in check-out and submit buttons won't talk to it. Teams work on the mounted drive directly and use the Desktop App or the swarmfile CLI for locks and commits.
• Perforce-compatible commands. The swarmfile CLI uses its own verbs (and understands many git habits, see Coming from Git); it doesn't accept p4 command lines.

If one of these is a blocker for your move, tell us - it helps us decide what to build next.