VisualSVN e le librerie di classi non nella radice della copia di lavoro

Question

Stiamo passando da SourceGear Vault a TortoiseSVN con VisualSVN per l'integrazione di Visual Studio: lo adoro. Tuttavia, ci sono più librerie di classi a cui facciamo riferimento in più applicazioni diverse che non fanno parte della radice della copia di lavoro in nessuna delle applicazioni. Qual è il modo migliore per gestirlo in modo da poter continuare a utilizzare l'integrazione di Visual Studio, mantenendo comunque le varie librerie di classi al di fuori della radice di ogni progetto / applicazione? SourceGear non ha problemi con questo.

È possibile aggiungere librerie di classi separatamente semplicemente usando TortoiseSVN in explorer, ma non è possibile eseguire il commit di modifiche a qualsiasi cosa al di fuori della copia di lavoro da Visual Studio; né ci sono i "semafori" di VisualSVN indicando lo stato per queste librerie di classi di copie esterne al lavoro.

A proposito, andremo anche con il "solo repository con molti progetti" percorso rispetto a più repository, soprattutto perché è così che abbiamo lavorato per anni fino a questo punto.

UPDATE:

Ho riletto alcune cose che avevo visto in precedenza e ho scoperto che svn: externals non si riferisce solo all'uso del codice in diversi repository, ma può anche essere usato per usare più copie funzionanti in VisualSVN.

Vedi http://www.visualsvn.com/support/topic/00007/ e http://svnbook.red-bean.com/ it / 1.2 / svn.advanced.externals.html

Tuttavia, è questo il modo migliore per affrontare questo problema? C'è un buon thread che passa attraverso le cose, ma non si risolve completamente le cose.

Pertanto, utilizzare svn: externals o no? Utilizzare più repository o no? Ancora una volta, per anni abbiamo fatto riferimento al codice nelle librerie di classi condivise tra più soluzioni / applicazioni e questo funziona per noi. Ora il modo migliore per farlo funzionare con VisualSVN?

Answer 1

Trovate le risposte migliori qui :

Progetti referenziati

A volte è utile costruire una copia funzionante composta da un numero di checkout diversi. Ad esempio, è possibile che si desideri che diverse sottodirectory provengano da posizioni diverse in un repository, o forse da repository diversi del tutto. Se si desidera che ogni utente abbia lo stesso layout, è possibile definire le proprietà svn: externals.

E qui :

Includi un sottoprogetto comune

A volte vorrai includere un altro progetto nella tua copia di lavoro, forse un codice di libreria. Non vuoi duplicare questo codice nel tuo repository perché perderai la connessione con il codice originale (e gestito). O forse hai diversi progetti che condividono il codice principale. Esistono almeno 3 modi per gestirlo.

Answer 2

So che sono passati più di dieci anni da quando hai posto questa domanda, ma sono felice di dirti che ci sono stati progressi nell'implementazione del supporto per più copie funzionanti nel plug-in VisualSVN. VisualSVN 7.1.0-alpha1 è ora disponibile per i test e include il supporto sperimentale per più copie funzionanti in un'unica soluzione .

Si prega di consultare la pagina dei download pre-release . Nota che la nuova versione supporta solo Visual Studio 2019.

PS Vedi l'articolo KB7: utilizzo di più copie funzionanti in VisualSVN . Lo aggiorneremo anche molto presto.