Alternativa esterna SVN nel server di team building 2012

Question

Attualmente utilizziamo SVN per il controllo del codice sorgente. A causa delle funzionalità extra e dell'integrazione nell'ambiente di sviluppo, vorremmo migrare a TFS 2012.

Abbiamo molti portali in esecuzione che sono stati creati in asp.net. All'interno del nostro portale utilizziamo molti componenti standard. Attualmente tutti i portali utilizzano lo stesso codice base. Ciò significa che ogni volta che modifichiamo qualcosa nella base di codice condivisa è (ogni volta che un portale è pubblicato) distribuito automaticamente. Siamo molto abituati a questo modo di lavorare e sappiamo che c'è il rischio di rompere il codice in altri portali. Tuttavia, pubblicare le modifiche in tutti gli altri portali costerebbe molto tempo. Quindi per fare ciò usiamo gli esterni in SVN.

Mi piacerebbe davvero mantenere questa funzionalità attiva e funzionante. Quindi la mia domanda è, c'è un modo per creare un sistema simile esterno in SVN o c'è un modo davvero buono che funziona altrettanto efficace per sostituire questa funzionalità.

Answer 1

Ci sono un paio di suggerimenti nello Visual Studio Team Foundation Server Branching and Merging Guide.

Se si scarica il pacchetto "Tutto" e si visualizza il file zip "Tutte le guide" e si legge "Guida al controllo delle versioni avanzate".

Pagine 5-19 (versione 2.1) copertina Gestione risorse condivise, c'è molto da fare e riassumere tutto per Stack Overflow probabilmente farà del Ranger un'ingiustizia, quindi ti indicherò semplicemente lì.

Answer 2

Bottom line: No TFS non ha l'equivalente di "svn: externals".

La condivisione del codice è BAD e porta alla duplicazione del codice e non al riutilizzo del codice. Dipende invece dal codice compilato.

Si dovrebbe dipendere solo dall'output della libreria condivisa e non dai file di origine. Per quanto riguarda gli scenari, non riesco a pensare a scenari in cui sia consigliabile condividere file di origine tra prodotti/soluzioni.

La ragione è che le cose possono diventare complicate e ingombranti molto rapidamente. Che cosa succede se si dispone di spostare di uno dipendente da una libreria condivisa che tutti cambiano per lo stesso codice e si alternano a vicenda. L'unico modo per farlo è iniziare a ramificare il tuo codice comune negli altri progetti che ora aggiunge un livello di complessità e integrazione che non verrà mai gestito nel lungo periodo e ti ritroverai con tre o più versioni della stessa base di codice su tempo.

Quello che dovresti fare è avere un singolo componente centrale che viene modificato e costruito per produrre output. Questo output può quindi essere attivato su richiesta negli altri progetti che dipendono da tali modifiche o meno. Ciò si traduce in un minor numero di rotture, una migliore architettura e un debito meno tecnico.

È persino possibile introdurre NuGet nell'equazione utilizzando un server interno ospitato per pubblicare il componente comune e informare ciascuno degli utenti quando è disponibile una nuova versione.