Come mai le soluzioni di controllo del codice sorgente centralizzate non eseguono la ramificazione

Quando i sistemi centralizzati creano un ramo, fanno varie cose . Perforce e Subversion sono unique nell'uso delle directory per i rami, e più tardi copiano l'idea dal primo. CVS ha filiali come concetto separato dalle directory e così fa la maggior parte degli altri sistemi di controllo delle versioni centralizzati.

L'uso delle directory per le filiali in Subversion è una riduzione apparente rispetto a un concetto più elementare che sfortunatamente ha i suoi aspetti negativi, perché l'unione ha senso solo per i rami, ma deve essere implementata per le directory arbitrarie in questo modello ed è generalmente complicata molto da questo.

L'uso di sottodirectory per le filiali non è adatto ai sistemi distribuiti, perché i rami sono la base per la distribuzione e quindi devono essere un concetto separato di prima classe.

La vera differenza tra la ramificazione nei sistemi centralizzati e distribuiti è che nei sistemi centralizzati per creare un ramo devi chiedere al server centrale, che significa nominare il ramo in un modo per evitare conflitti e round-trip al server e così via nel sistema distribuito ogni checkout è un ramo per progetto, quindi lo hai sempre quando ne hai bisogno.

E si noti che anche nel sistema centralizzato il checkout contenente le modifiche locali è una specie di ramo (ad eccezione delle viste dinamiche ClearCase). È solo un ramo con funzionalità molto limitate che può contenere solo le modifiche non vincolate.

Alcune note aggiuntive:

Subversion può cambiare ramo in un particolare checkout.

Subversion crea una nuova directory per un ramo, ma non duplica il contenuto dei file, quindi non c'è davvero molta differenza nell'efficienza dello storage.

Un sistema distribuito (in cui l'identità di revisione viene mantenuta durante lo spostamento tra repository) non può utilizzare le directory per le filiali, ma esiste un sistema decentralizzato, SVK , che è costruito sopra a subversion e usa le directory per i rami e funziona tramite il mirroring dei repository di subversion.

È un effetto valanga.

SVN ha funzionato da molto, molto tempo e la duplicazione di una directory era la soluzione facile da usare. Era abbastanza buono perché la ramificazione era rara. Ma poi DVCS sono stati inventati in parte per superare le debolezze percepite in SVN, e avevano un supporto ramificato efficace ed efficiente. Ciò ha portato le persone a utilizzare molto più ramificazioni che mai, il che ha reso ancora più importante il fatto che le diramazioni siano a buon mercato, quindi ora è impensabile tornare alla soluzione facile da utilizzare.

Quindi la ragione è l'incidente storico piuttosto che il modello di sviluppo - è più o meno una coincidenza che Linus abbia introdotto allo stesso tempo branching e storage distribuito migliorati (tramite git). Certamente potresti programmare un'archiviazione efficiente in qualsiasi VCS, se lo desideri.

Il software legacy non è progettato, si evolve. Svn è stato progettato per migliorare CVS, che è stato progettato per migliorare RCS. Cosa ha sostituito RCS? Pensa a come manterrai le filiali senza alcun sistema di controllo della versione. Li metti in directory separate.

Mettere queste directory separate sotto controllo di versione richiede un salto minore nel tuo modello mentale rispetto al sistema di git, che sembra un evidente miglioramento rispetto a svn, ma è tutt'altro che ovvio se paragonato a nessun VCS.

Tieni anche presente che gli switch di ramo sono molto più veloci sui sistemi di controllo delle versioni distribuite perché non devono andare in rete. Al lavoro in cui probabilmente hai una connessione gigabit al tuo server, non è un grosso problema. Quando fu inventato il CVS, 9600 baud erano considerati una connessione ad alta velocità. Dischi e CPU erano anche molto più lenti di allora. Un git checkout di un progetto che la dimensione del kernel di Linux avrebbe potuto richiedere diversi minuti sui computer di quell'epoca.

Detto questo, molti dei tuoi criteri per chiamare il modello di git "superiore" non sono necessariamente accurati. Il mio computer di sviluppo al lavoro ha un disco di terabyte su di esso. Ho quattro filiali controllate da un progetto di 60.000 file e sto ancora usando solo 80 GB, e questo include il mio sistema operativo e tutto il resto. Chiaramente, la duplicazione non è un problema. Per quanto riguarda il cambio di rami, git è veloce, ma un cd è ancora più veloce.

Nel tempo il software tende a prendere in prestito le migliori caratteristiche dei concorrenti, e penso che i check-out sul posto saranno alla fine un'opzione nella maggior parte dei sistemi di controllo delle versioni centralizzati. Non c'è nulla che lo impedisca intrinsecamente oggi, solo la storia. In effetti, potrebbe essere già disponibile e semplicemente non lo stai utilizzando. Ad esempio, flussi Perforce consentono la ramificazione sul posto.