Enmarcar la decisión

"¿Qué VCS deberíamos usar?" rara vez tiene una respuesta correcta. El frame correcto es: "¿Qué restricciones impone nuestro trabajo, y qué sistema encaja mejor?"

El caso honesto a favor de Perforce

Este artículo es un contrapeso. La mayoría de blogs modernos asumen que Git es la respuesta. Para un conjunto significativo de proyectos, Perforce es genuinamente la mejor elección.

Señal 1: cargas binary-heavy

Si tus commits diarios incluyen modelos FBX, archivos PSD, WAVs de varios gigabytes, footage de cámara raw, ensamblajes CAD, o artefactos de engine compilados, el diseño de Perforce encaja con el trabajo.

La cuestión del costo

Perforce / Helix Core es software comercial. El precio varía pero típicamente cae alrededor de USD 25-50 por usuario por mes para hosting cloud.

Por qué importa el locking

Algunos archivos no se pueden mergear. Un modelo 3D en .fbx, un archivo Photoshop en .psd, un ensamblaje CAD — todos son binarios, y las ediciones concurrentes no pueden reconciliarse.

El modelo de locking de Perforce

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

p4 lock character.fbx
p4 unlock character.fbx

El modelo nativo de Git

Git no tiene concepto de locks exclusivos.

Diferentes problemas, diferentes soluciones

Perforce fue lanzado en 1995 — una década antes de Git o Mercurial. Apunta a una forma particular de problema: contenido grande, a menudo binario; flujos altamente regulados; equipos que necesitan control de acceso granular y locks exclusivos.

Arquitectura

Perforce es centralizado, como SVN, pero diseñado para escala muy más allá del uso típico de SVN. Git es distribuido — cada clone es un repositorio completo.

El punto de inflexión de 2005

BitKeeper había sido el VCS del kernel Linux hasta abril de 2005, cuando disputas de licencia terminaron ese acuerdo. Linus Torvalds escribió Git en 10 días. Matt Mackall comenzó Mercurial semanas después.

El factor Linux

El kernel Linux es el proyecto open source más grande e influyente en la historia. Su elección de Git significaba que los contribuidores del kernel usaban Git.

Vocabulario de rendimiento

"Rendimiento a escala" puede significar muchas cosas: tiempo de clone, velocidad de log/blame, throughput de commits, manejo de tamaño del árbol de trabajo.

Clone y fetch

Los archivos pack de Git usan compresión delta agresiva. Mercurial usa archivos bundle con compresión similar.

Operaciones locales

Ambos sistemas realizan operaciones locales completamente desde disco. El núcleo Python puro de Mercurial fue históricamente más lento.

Dos formas de ecosistema

El ecosistema de Git es esparcido, dirigido por mercado y desigual. El de Mercurial es más pequeño, deliberado y más cohesivo.

Hosting

El hosting Git está en todas partes. El hosting Mercurial se ha adelgazado dramáticamente: Bitbucket eliminó Mercurial en 2020.

Integraciones CI/CD

Cada servicio CI principal soporta Git nativamente. El soporte Mercurial existe pero es irregular.

Soporte IDE

VS Code, JetBrains, Vim, Emacs, Sublime Text, Visual Studio — todos tienen integración Git de primera clase.

Dos linajes de diseño

El CLI de Git emergió orgánicamente. El CLI de Mercurial fue diseñado top-down por Matt Mackall.

Consistencia de comandos

Mercurial usa verbo-nombre consistentemente. Las opciones son consistentes: -r siempre significa revisión, -m siempre mensaje. Los verbos de Git se solapan.

Texto de ayuda

hg help commit         # enfocado, corto, relevante
git help commit         # página de manual exhaustiva

Mensajes de error

Mercurial famosamente tiene errores más amigables.

Misma era, estética diferente

Git y Mercurial fueron lanzados en abril de 2005, ambos como respuesta a las disputas de licencia de BitKeeper. Linus Torvalds escribió Git para el kernel Linux; Matt Mackall escribió Mercurial como alternativa.

La postura de Git: poder, bordes, confiar en el usuario

Git expone sus internals. Los comandos plumbing están documentados. Reescribir la historia se fomenta. El usuario es presumido competente.