Différents problèmes, différentes solutions

Perforce a été lancé en 1995 — une décennie avant Git ou Mercurial. Il vise une forme particulière de problème : contenu volumineux, souvent binaire; workflows hautement régulés; équipes qui ont besoin de contrôle d'accès granulaire et verrous exclusifs.

Architecture

Perforce est centralisé, comme SVN, mais conçu pour une échelle bien au-delà de l'usage typique de SVN. Git est distribué.

Ce que Perforce fait brillamment

• Verrouillage de fichiers.
• Streams - branching déclaratif.
• Sécurité par chemin.
• Repos massifs.
• Submits atomiques entre fichiers.
• Intégration mature.

Ce que Git fait brillamment

• Branching et merging bon marché pour le travail code-heavy.
• Historique distribué.
• Écosystème massif.
• Intégration avec les workflows modernes de code review.
• Coût - Git est gratuit; Perforce est licencié.

Commandes quotidiennes

# Perforce
p4 sync
p4 edit file.txt
p4 submit -d "Edit"
p4 changes

# Git
git pull
git add file.txt
git commit -m "Edit"
git push
git log

Branching

p4 stream -P main //my-depot/release
p4 stream -P main //my-depot/feature-x

Verrouillage

p4 edit -t binary+l character.fbx

Cas d'usage où Perforce gagne

• Développement de jeux avec téraoctets d'assets.
• Studios VFX avec sorties de rendu massives.
• Conception hardware avec fichiers CAD binaires.
• Industries régulées nécessitant des trails d'audit granulaires.

Cas d'usage où Git gagne

• Logiciel open source.
• Développement web et mobile.
• Développement de bibliothèques et SDKs.
• Là où le workflow est "branch, PR, merge".

Approches hybrides

Beaucoup de grands studios font tourner Git pour le code et Perforce pour le contenu.

Coût

Les licences Perforce / Helix Core sont par utilisateur et pas bon marché.