Cadrer la décision

"Quel VCS devrions-nous utiliser ?" a rarement une réponse correcte. Le bon cadrage est : "Quelles contraintes notre travail impose-t-il, et quel système convient le mieux ?"

Le cas honnête pour Perforce

Cet article est un contrepoids. La plupart des blogs d'ingénierie modernes assument que Git est la réponse. Pour un ensemble significatif de projets, Perforce est véritablement le meilleur choix.

Signal 1 : charges binary-heavy

Si vos commits quotidiens incluent des modèles FBX, fichiers PSD, WAVs multi-gigaoctets, footage caméra brut, assemblages CAD, ou artefacts d'engine compilés, le design de Perforce convient.

La question du coût

Perforce / Helix Core est un logiciel commercial. Le tarif varie mais tombe typiquement autour de 25-50 USD par utilisateur par mois pour le hosting cloud.

Pourquoi le verrouillage compte

Certains fichiers ne peuvent pas être mergés. Un modèle 3D en .fbx, un fichier Photoshop en .psd, un assemblage CAD — tous sont binaires.

Le modèle de verrouillage de Perforce

p4 edit character.fbx
p4 submit -d "Update rig"

p4 lock character.fbx
p4 unlock character.fbx

Le modèle natif de Git

Git n'a pas de concept de verrous exclusifs.

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é.

Le point d'inflexion de 2005

BitKeeper avait été le VCS du kernel Linux jusqu'à avril 2005, quand des disputes de licence ont mis fin à cet arrangement. Linus Torvalds a écrit Git en 10 jours.

Le facteur Linux

Le kernel Linux est le plus grand projet open source de l'histoire. Son choix de Git signifiait que les contributeurs du kernel utilisaient Git.

Vocabulaire de performance

"Performance à l'échelle" peut signifier beaucoup de choses : temps de clone, vitesse de log/blame, throughput de commits.

Clone et fetch

Les pack files de Git utilisent agressivement la compression delta. Mercurial utilise des bundle files avec une compression similaire.

Opérations locales

Les deux systèmes effectuent les opérations locales entièrement depuis le disque. Le cœur Python pur de Mercurial était historiquement plus lent.

Deux formes d'écosystème

L'écosystème de Git est tentaculaire, dirigé par le marché et inégal. Celui de Mercurial est plus petit, délibéré et plus cohésif.

Hosting

Le hosting Git est partout. Le hosting Mercurial s'est aminci dramatiquement : Bitbucket a abandonné Mercurial en 2020.

Intégrations CI/CD

Chaque service CI majeur supporte Git nativement. Le support Mercurial existe mais est inégal.

Support IDE

VS Code, JetBrains, Vim, Emacs, Sublime Text, Visual Studio — tous ont une intégration Git de première classe.

Deux lignées de conception

La CLI de Git a émergé organiquement. La CLI de Mercurial a été conçue top-down par Matt Mackall.

Cohérence des commandes

Mercurial utilise verbe-nom de manière cohérente. Les options sont cohérentes : -r signifie toujours révision, -m toujours message.

Texte d'aide

hg help commit         # focalisé, court, pertinent
git help commit         # page de manuel exhaustive

Messages d'erreur

Mercurial est célèbre pour ses erreurs plus amicales.

Même époque, esthétique différente

Git et Mercurial ont tous deux été lancés en avril 2005, tous deux comme réponses aux disputes de licence de BitKeeper. Linus Torvalds a écrit Git pour le kernel Linux; Matt Mackall a écrit Mercurial.

La position de Git : puissance, bords, faire confiance à l'utilisateur

Git expose ses internals. Réécrire l'historique est encouragé. L'utilisateur est présumé compétent.