Die Entscheidung framen

"Welches VCS sollten wir verwenden?" hat selten eine richtige Antwort.

Der ehrliche Fall fur Perforce

Dieser Artikel ist ein Gegengewicht. Die meisten modernen Engineering-Blogs nehmen an, dass Git die Antwort ist.

Signal 1: binar-lastige Workloads

Wenn Ihre taglichen Commits FBX-Modelle, PSD-Dateien, Multi-Gigabyte-WAVs, Raw-Camera-Footage, CAD-Assemblies oder kompilierte Engine-Artefakte enthalten, passt Perforces Design zur Arbeit.

Signal 2: Locking ist nicht optional

Wenn Ihr Team jemals den Tagesarbeit eines Kunstlers verloren hat, weil zwei Personen dieselbe Szene bearbeitet haben.

Die Kostenfrage

Perforce / Helix Core ist kommerzielle Software. Preise variieren je nach Plan, aber landen typischerweise bei 25-50 USD pro Benutzer pro Monat.

Warum Locking zahlt

Einige Dateien konnen nicht gemerged werden. Ein 3D-Modell in .fbx, eine Photoshop-Datei in .psd.

Perforces Locking-Modell

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

p4 lock character.fbx
p4 unlock character.fbx

Git's natives Modell

Git hat kein Konzept exklusiver Locks.

Verschiedene Probleme, verschiedene Losungen

Perforce wurde 1995 veroffentlicht. Es zielt auf eine bestimmte Art von Problem.

Architektur

Perforce ist zentralisiert, wie SVN, aber fur Massstab weit jenseits von SVNs typischer Verwendung konstruiert.

Der 2005-Wendepunkt

BitKeeper war der VCS des Linux-Kernels bis April 2005. Linus Torvalds schrieb Git in 10 Tagen.

Der Linux-Faktor

Der Linux-Kernel ist das grosste, einflussreichste Open-Source-Projekt der Geschichte.

Der GitHub-Faktor

GitHub startete im April 2008. Bis 2010 war GitHub der OSS-Hub.

Netzwerkeffekte

Die Kosten des VCS-Wechsels skalieren mit Teamgrosse und Okosystem-Investment.

Performance-Vokabular

"Performance im Massstab" kann viele Dinge bedeuten.

Klon und Fetch

Git's Pack-Files verwenden aggressive Delta-Kompression. Mercurial verwendet Bundle-Files mit ahnlicher Kompression.

Lokale Operationen

# Benchmark: log on a million-commit repo
time git log --oneline | wc -l
time hg log --template '{rev}\n' | wc -l

Working-Tree-Grosse

Beide Systeme machen Datei-Tree-Updates durch Tree-Walking.

Speicherverbrauch

Mercurials Python-Runtime erzwingt einen hoheren Speicher-Floor.

Zwei Okosystem-Formen

Git's Okosystem ist riesig, marktgetrieben und ungleichmassig. Mercurials ist kleiner, deliberativ und koharenter.

Hosting

Git-Hosting ist uberall. Mercurial-Hosting ist drastisch geschrumpft.

CI/CD-Integrationen

Jeder grosse CI-Service unterstutzt Git nativ.

IDE-Unterstutzung

VS Code, JetBrains, Vim, Emacs, Sublime Text, Visual Studio — alle haben erstklassige Git-Integration.

Erweiterungs-Architekturen

Mercurial-Erweiterungen plugen sich in eine stabile Python-API. Notable Erweiterungen:

Zwei Design-Stammbaume

Git's CLI entstand organisch. Mercurials wurde top-down entworfen.

Befehlskonsistenz

Mercurial verwendet Verb-Substantiv konsistent.

Hilfetext

hg help commit
git help commit

Fehlermeldungen

Mercurial hat bekannt freundlichere Fehler.

Sichere Defaults

Mercurial-Befehle zerstoren selten Daten ohne explizite Erweiterung.

Gleiche Ara, andere Asthetik

Git und Mercurial wurden beide im April 2005 veroffentlicht.

Git's Haltung: Macht, Kanten, dem Benutzer vertrauen

Git legt seine Internals offen.

Mercurial's Haltung: Sicherheit, Konsistenz, Konservatismus

Mercurial verbirgt Internals aggressiver.