Repositorios

Na hora de organizar un sistema de control de versións a pregunta de moda é: “mono­rre­po­si­torio ou multi­rre­po­si­torio?”. É dicir: poñemos todos os proxectos nun só repositorio de control de versións, ou dividímolos e poñemos un proxecto en cadanseu repositorio?

Na miña opinión, a maioría dos lectores da Folla debería usar un mono­rre­po­si­torio. O motivo é simple: os multi­rre­po­si­torios teñen moitas desvantaxes respecto dos mono­rre­po­si­torios, pero case todos os inconvenientes que se lle achacan aos mono­rre­po­si­torios tamén os teñen os multi­rre­po­si­torios, porque eses inconvenientes non son problemas técnicos, senón organizativos.

Imaxinade o caso dun proxecto grande con varias partes ben diferenciadas: backend en Java, frontend web en Typescript, cliente Android en Kotlin e cliente iOS en Swift. É moi habitual querer poñer cada parte nun repositorio diferente. Desta maneira, os programadores que traballan nunha parte non teñen que descargar o código das outras partes nas que non traballan.

Bo era.

Este beneficio non existe. As partes nas que se divide un proxecto case nunca son totalmente independentes, así que a separación entre os distintos repositorios non é hermética. Por exemplo, é seguro que o backend e os frontends comparten os ficheiros que definen os modelos de datos. Ademais, engadir unha nova funcionalidade normalmente precisa de cambios no backend e en todos os frontends. Polo tanto, no final, case todos os programadores van precisar de ter acceso a case todos os repositorios.

Outro problema propio dos multi­rre­po­si­torios é que non son atómicos.

Nun sistema de control de versións moderno, se alguén fixo un cambio que afectaba a cincuenta ficheiros, non é posible descargar unha versión incompleta dese cambio: o cambio aparece completo ou non aparece. Ou sexa, é atómico.

Nun multi­rre­po­si­torio, os cambios son atómicos dentro de cada repositorio, pero non son atómicos no conxunto dos repositorios. Se alguén fixo un cambio no backend e no frontend ao mesmo tempo, é trivial descargar unha versión incompleta na que só figuran os cambios feitos nun só repositorio.

Isto parece unha parvada pero fai que, por exemplo, os sistemas de integración continua non sexan confiables nun multi­rre­po­si­torio. Nun mono­rre­po­si­torio podemos estar seguros de que, se hai erros na integración continua, é porque o código contén erros. Nun multi­rre­po­si­torio, os erros poden estar causados porque a integración continua tratou de compilar unha mestura de versións distintas procedentes de distintos repositorios.

Hai xente que pensa que é máis doado facer control de acceso nun multi­rre­po­si­torio. Se Pepe só traballa no frontend, abondaría con lle dar acceso ao repositorio do frontend; se Maruxa traballa no cliente de iOS, abondaría con lle dar acceso ao repositorio de iOS. Isto non funciona porque, como xa expliquei, Pepe e Maruxa case sempre van precisar de acceso a varios repositorios, non só ao “seu”. Polo tanto, é necesario outro mecanismo de control de acceso — que, casualmente, vai ser exactamente o mesmo mecanismo do que se precisa nun mono­rre­po­si­torio, así que a avantaxe non existe.

Un caso no que un mono­rre­po­si­torio pode ser inferior a un multi­rre­po­si­torio é cando este mono­rre­po­si­torio contén moitos gigabytes de información. Daquela é posible que as ferramentas habituais non funcionen cun repositorio tan grande — ou, incluso, que non caiba nun ordenador normal, e é preciso utilizar cousas como sistemas de ficheiros virtuais, buscadores, sistemas de compilación distribuídos e outras ferramentas polo estilo.

Pero deixádeme que vos diga unha cousa: a maioría dos lectores da Folla non ides ter este problema. Usade un mono­rre­po­si­torio sen medo e xa pensaredes nalgo se algún día chegades a ese punto.

A ilustración desta Folla procede dunha postal da “Detroit Creamery Certified Milk Farm”.