Toca programa de testimonios: Eu era un usuario de subversion que durante moitos anos estivo moi satisfeito, ata que hai uns poucos meses coñecín git. Dende entón, de poder elexir, non volvería a tocar subversion ou calquera outro sistema de control de versións centralizado. De igual xeito que subversion supuña máis liberdade fronte a CVS, os sistemas de control de revisións distribuídos supoñen máis liberdade fronte ós centralizados. E é moi doado acostumarse ás novas liberdades.

Os sistemas de control de versións distribuídos (SCVD en adiante) libres non son novos: GNU arch comezou no 2001, bazaar, git e mercurial no 2005. O desenvolvemento de GNU arch abandonouse no 2008 debido á súa falta de competitividade co resto de alternativas libres. Por que se produciu esa explosión de SCVDs no 2005? Por un claro exemplo de porque un non se pode fiar do software privativo. BitKeeper, un SCVD privativo, durante un par de anos permitiu o uso dunha versión moi capada de forma gratuíta para o desenvolvemento de proxectos de software libres. No abril de 2005 anunciouse que este servizo gratuíto deixaríase de dar e uns días despois, no mesmo abril, anunciáronse tanto git coma mercurial. Software privativo is evil!

Se non probara antes un SCVD foi por non entender que é un SCVD, algo que penso é bastante común. Eu entendía as avantaxes que un SCVD supuña para un proxecto grande, pero non para uso persoal. A diferenza entre un sistema de control de versións centralizado e un distribuído é que no centralizado existe un respositorio (código fonte e historia dos cambios feitos) central mentres que nun sistema distribuído cada usuario ten un repositorio (aínda que hai un repositorio que fai de repositorio principal do proxecto). Os dous sistemas teñen fluxos de traballo distintos. Este novo fluxo de traballo permite facer cousas imposibles cun sistema centralizado.

Uns exemplos do que permiten os SCVD:

  1. Arranxo de erros triviais dun commit: Pódese arranxar un erro nun commit que aínda non se subiu sen ter que crear outro commit especificamente para isto. Con isto simplifícase a historia do repositorio ao eliminar commits innecesarios.
  2. Reordenación de commits: Pódense organizar os commits que aínda non se subiron e colocar xuntos os commits relacionados. Con isto auméntase a lexibilidade da historia do repositorio.
  3. Unificación de commits: Pódense xuntar varios commits que aínda non se subiron nun único commit. Este é un paso lóxico despois da reordenación dos commits: varios commits pequenos sobre o mesmo que quedan mellor xuntos.

A insistenza sobre “commits que aínda non se subiron” é a propósito. Ó non ter que subir cada commit que fas, pódelo modificar como queiras. Pero, unha vez subido xa non se poden modificar posto que xa é visible ao resto dos clientes e calquera modificación podería resultar en incoherencias nos repositorios.

En resumo, cun SCVD podes ter un historial máis limpo e coidado. Acabas mimando o historial de commits, unha oportunidade que nun sistema centralizado non se ten.


Categories

Calendario

Marzo 2010
M T W T F S S
« Dec    
1234567
891011121314
15161718192021
22232425262728
293031  
3K2 theme by Hakan Aydin