Ho letto qui alcune risposte che condannano l'uso di svn: esterni. Vedo come possono essere usati impropriamente, e ci rende più dipendenti da Subversion, ma davvero non vedo il nostro gruppo allontanarsi da esso in qualsiasi momento presto.svn esternals ... si o no?
In ogni caso, ecco il mio dilemma. Abbiamo soluzioni che fanno riferimento a più progetti che si trovano nella propria sezione del repository. Molti di questi progetti sono condivisi tra più soluzioni e inoltre non vogliamo precludere la condivisione dei nostri progetti. Abbiamo anche diverse dipendenze delle versioni fisse controllate nel nostro repository (framework di test unitari, librerie, ecc.).
Vorrei configurare diversi 'spazi di lavoro' che utilizzano ESCLUSIVAMENTE gli aspetti esterni (per quanto riguarda Subversion sarebbero solo directory vuote o potrebbero contenere un singolo file di soluzione) per configurare Soluzioni per i nostri sviluppatori. La verifica della maggior parte dei progetti da soli non sarà sufficiente per crearli, ma controllare il suo spazio di lavoro sarà sufficiente per costruirlo perché tutte le sue dipendenze verranno con esso. Qualcun altro ha implementato una soluzione simile e sarebbe svn: gli esterni sono un buon modo per fare questo? Quali parole di cautela hai per me se percorriamo questa strada?
In sostanza la struttura sarebbe simile a questa (tronco/rami/tag omesse per brevità):
/projects
/project1
/project2
/dependencies
/xUnit
/1.5
/1.4
/NHibernate
/2.1.0
/2.0.1
/workspaces
/project1
/project1 (external to ^/projects/project1)
/xUnit (external to ^/dependencies/xUnit/1.5)
/NHibernate (external to ^/dependencies/NHibernate/2.0.1)
/project2
/project2 (external to ^/projects/project2)
/xUnit (external to ^/dependencies/xUnit/1.4)
/NHibernate (external to ^/dependencies/NHibernate/2.1.0)
Nota che il collegamento per quel post del blog è stato spostato.Ora è qui: http://cobaltedge.com/svn-externals-are-evil-use-piston-or-braid – chrisrbailey