Por qué esto le interesó a Greg Foster, desarrollador de Graphite
- Empezó el proyecto Graphite inspirado en herramientas internas de Facebook
- Después de que colegas ex-Facebook le presentaran Mercurial y el flujo de trabajo de "stacked diffs", decidió llevarlo a los desarrolladores de GitHub, y terminó creando un CLI que integra ideas de Hg en Git
- ¿Por qué Facebook adoptó Mercurial en vez de Git y construyó un flujo de trabajo personalizado encima?
- Google tampoco usa Git, pero eso se debe a que la ingeniería de Google llevaba más de 5 años de ventaja frente a Git
- En cambio, Facebook fue fundada en 2004, más o menos cuando se creó Git, y para cuando Facebook empezó a evaluar en serio herramientas de control de código fuente, Git ya era más popular que Mercurial
- Entonces, ¿por qué Facebook no usa Git?
- Él cree que si Facebook hubiera adoptado Git y contribuido a él a inicios de la década de 2010, el mundo de la ingeniería sería distinto
- Git podría haber sido más amigable para el usuario y haber soportado Stacked Changes de forma nativa
- Empresas creadas por primeros empleados de Facebook, como Uber y Pinterest, también habrían usado Git y GitHub como control de código fuente en vez de Mercurial, creando un ecosistema menos fragmentado en los últimos 10 años
- Pero Facebook no se quedó con Git (para su monorepo principal). En su lugar, adoptó Mercurial para el control de versiones y fue agregando gradualmente herramientas personalizadas encima
- Encontró la publicación de Facebook Scaling Mercurial at Facebook
- Es un artículo de hace 10 años, y después, a través de varios videos de YouTube, obtuvo la respuesta de que "era por rendimiento"
- Pero quiso ir más a fondo y escuchar qué pensaban quienes tomaron la decisión en ese momento, así que les preguntó a dos ingenieros que participaron en el proyecto de migración a Mercurial
- Organizó este contenido a partir de conversaciones informales con ellos
Por qué Facebook dejó Git y migró a Mercurial
- Facebook usó Git al principio, pero alrededor de 2012 empezó a sufrir problemas de rendimiento a medida que crecía el tamaño de su base de código
- El proceso de
stat de archivos en Git se convirtió en un cuello de botella, y ejecutar comandos básicos de Git tardaba más de 45 minutos
- Los mantenedores de Git no fueron colaborativos frente a los problemas de Facebook con repositorios a gran escala, y en cambio recomendaron dividir el repositorio
Alternativas que se consideraron
- En 2012 no había muchas alternativas a Git, y Facebook consideró soluciones de código cerrado como Perforce, pero tenían problemas técnicos
- Mercurial tenía un rendimiento similar al de Git, pero contaba con una arquitectura más limpia y mayor extensibilidad
- El equipo de Facebook participó en un hackathon de Mercurial y quedó impresionado por la extensibilidad de Mercurial y la apertura de su comunidad
La migración de toda la organización de ingeniería
- Para convencer al resto de la empresa, el equipo de Facebook mapeó comandos y flujos de trabajo entre Git y Mercurial, y se tomó tiempo para escuchar las preocupaciones de los desarrolladores
- La migración se llevó a cabo con cuidado y, finalmente, Facebook cambió a Mercurial
- Facebook contribuyó a mejorar el rendimiento de Mercurial y a permitir la paralelización de revisiones de código mediante "stacked diffs"
Reflexiones finales
- Esta historia recuerda que "muchas decisiones técnicas importantes no están impulsadas por la tecnología, sino por las personas"
- Facebook eligió Mercurial no porque rindiera mejor que Git, sino porque la colaboración con los mantenedores de Mercurial era más abierta
- En el proceso de convencer a toda la organización de ingeniería, lo importante no fue que una tecnología fuera superior a otra, sino la "comunicación reflexiva"
- Se enfatiza que la "comunicación y la amabilidad" son valores importantes en el mundo de las herramientas de desarrollo
2 comentarios
Me hace pensar en lo que dijo un conocido: "para convencer al cliente, hay que convertirse en su rascador de espalda"
No hace falta que sea demasiado filoso, ni demasiado rápido, ni demasiado cómodo, ni demasiado caro; con que pueda rascar justo donde lo quiere, eso es el servicio que el cliente quiere jaja
Como Git fue creado por Linus Torvalds para gestionar el código fuente de Linux, creo que probablemente había ciertos aspectos en los que no podía haber mucho margen de negociación.
La idea central de la reflexión final suena casi como si Git fuera malo porque no escuchó las necesidades de Facebook y no priorizó la comunicación ni la amabilidad, pero yo creo que simplemente tenían enfoques distintos en varios sentidos.
Visto al revés, Facebook también tenía la opción de aceptar y aplicar la división de repositorios que Git recomendaba. Simplemente no era el tipo de "amabilidad" que ellos querían.