Ho riflettuto su alcune strategie di ramificazione (creazione di rami per funzionalità, forse per sviluppatore poiché siamo un piccolo gruppo) e mi chiedevo se qualcuno avesse riscontrato problemi. La creazione di un ramo occupa molto spazio?TGB Ramificazione e spazio su disco
L'ultima volta che ho guardato, TFS utilizza la copia su scrittura, il che significa che non aumenterai lo spazio su disco finché non cambierai i file. È un po 'come usare i collegamenti simbolici finché non hai bisogno di cambiare le cose.
James è fondamentalmente corretto. Per una risposta più completa, abbiamo bisogno di iniziare con il post di Buck dal lontano 2006: http://blogs.msdn.com/buckh/archive/2006/02/22/tfs_size_estimation.aspx
Ogni nuova riga nella tabella versione locale aggiunge circa 520 byte (una riga viene aggiunto per ogni area di lavoro che ottiene il neo aggiunto elemento e la dimensione è dominata dalla colonna del percorso locale). Se si dispone di 100 aree di lavoro che ottengono l'elemento appena aggiunto, il database aumenterà di 52 KB. Se si aggiungono 1.000 nuovi file di dimensioni medie (mix di file di origine, file binari, immagini, ecc.) E si ottengono 100 spazi di lavoro, il database di controllo della versione aumenta di circa 112 MB (60 KB * 1.000 + 520 * 1.000 * 100) .
Possiamo omettere la cifra di 60 KB poiché gli elementi ramificati non duplicano il contenuto del file. (Non è abbastanza "copy-on-write", James - una quantità O (N) di metadati deve essere calcolata e memorizzata durante l'operazione stessa del ramo, contro sistemi come git che credo si ramificano in O (1) - ma hai ragione sul fatto che il nuovo oggetto punta allo stesso record in tbl_Content come elemento sorgente fino a quando non viene modificato). Questo ci lascia semplicemente con il fattore 520 * num_workspaces * files_per_workspace. Sul server MS dogfood ci sono qualcosa come 2 miliardi di righe in tbl_LocalVersion, ma in un piccolo gruppo auto-descritto dovrebbe essere assolutamente trascurabile.
Il blog di Something Buck non menziona la cronologia delle fusioni. Se si adotta un flusso di lavoro di tipo branch-heavy e lo si attacca attraverso diversi cicli di sviluppo, è probabile che tbl_MergeHistory cresca quasi come tbl_LocalVersion. Di nuovo, dubito che si possa registrare anche sul radar di una piccola squadra, ma su grandi installazioni si possono facilmente accumulare centinaia di milioni di file. Detto questo, ogni riga è molto più piccola poiché non ci sono campi nvarchar (260).
+1: La mia comprensione pure. Il ramo occuperà spazio sulla stazione di lavoro locale, ma puoi sempre Cloak del ramo se non vuoi vederlo (che in pratica lo elimina dal tuo Workspace) e sfoltirlo una volta che è stato fatto e unito nuovamente. – TrueWill
I non sono riuscito a trovare alcuna informazione su questo, quindi se qualcuno incontra qualche link, indicamelo. Grazie per la risposta. –