Imagina que estás trabajando en un proyecto para una compañía enorme, una multinacional, quizás un unicornio. En tu trabajo anterior trabajabas con sistemas de versiones tipo Git, así que llegas y haces el típico git clone para traerte el repositorio. Para tu asombro, descubres que ese repositorio ocupa la friolera de 270 Gb. Es una bestialidad, pero decides esperar mientras miras los requisitos que tu project manager te ha mandado hacer.
Tras la espera, piensas "voy a crearme una rama nueva para trabajar y así no molestar a nadie; cuando acabe lo uno con la de producción y listo". Haces un git checkout y ¡sorpresa! Te toca esperar un par de horitas para que se haga. "No puede ser", piensas. Te entra el pánico y decides ver el estado del repositorio (a ver si es que lo hiciste mal). git status y ¡venga esperar otros 10 minutos! Esto es de locos...
Ahora imagina que este supuesto no es tan supuesto, sino que es real. Que esa multinacional es Microsoft y que ese repositorio es el código de Microsoft Windows. Como es un problema realmente insostenible para los desarrolladores (Microsoft no puede tener a decenas personas de brazos cruzados esperando por un simple git status), sus ingenieros se han puesto manos a la obra y han creado una versión mejorada de Git a la que han llamado GVFS, siglas de Git Virtual File System (no confundir con Gnome Virtual File System).
GVFS lo que hace es virtualizar el sistema de ficheros del repositorio; de esta forma al desarrollador le da la sensación de que todos los ficheros están presentes cuando en realidad solamente son descargados la primera vez que se abren. Por lo general (al menos en mi experiencia) cuando se está añadiendo una característica nueva, o arreglando algún bug, se suelen tocar los mismos archivos una y otra vez. Es muy raro que haya que editar todos los archivos del proyecto, así que esto supone una mejora increíble cuando se trabajan con repositorios de miles de archivos (Microsoft Windows tiene unas 3.5 millones de líneas de código).
Además, en repositorios de estas dimensiones los desarrolladores no necesitan compilar todo el proyecto. En su lugar van descargando pequeñas porciones de la build final, y sólo compilan aquellas partes que afectan directamente a su desarrollo. Según Microsoft, un desarrollador medio descarga y usa entre 50 y 100 mil líneas de los casi 3 millones que componen el repositorio de Microsoft Windows.
Con este sistema, Microsoft ha conseguido que clonar un repositorio lleve únicamente unos minutos, que un checkout requiera 30 segundos en lugar de 2 o 3 horas, o que un status lleve 4 o 5 segundos en lugar de 10 minutos. Aunque estos tiempos sigan pareciendo bastante elevados, hay que tener en cuenta que son tiempos en frío; es decir, cuando hay que hacerlo todo desde cero en una máquina nueva. Si ya tenemos el repositorio y vamos cambiando de ramas y demás, estos tiempos serían los normales que manejamos "el resto de mortales" en nuestros repositorios.
¿Lo mejor de todo? Que Microsoft ha vuelto open-source este cliente. Además, también han hecho cambios en Git para permitir que se puedan utilizar este nuevo tipo de repositorio GVFS, y han implementado un protocolo de comunicación que tienen documentado aquí.
De momento parece que sólo funciona bajo Windows 10 ya que es un cliente de Git para Windows, aunque bastante gente está pidiendo que se haga también para Linux y MacOS. Esperemos que aunque no sea oficial, el poder de la comunidad open-source lo saque adelante. Porque yo no manejo repositorios tan grandes, pero si puedo rascar un par de segundos en mi trabajo diario con Git, pues mejor que mejor.