svn esternals ... si o no?

Question

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.

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) 

Answer 1

SVN Externals are Evil; Use Piston or Braid sembra tipica del campo anti-esterno. E il poster ha un punto.

Credo che un criterio migliore è:

• utilizzare i riferimenti esterni per progetti interni che si può cambiare; e
• Utilizzare vendor branches per repository esterni su cui non si ha alcun controllo.

così sembra i problemi con gli esterni svn provengono da persone li usano come sostituto per le filiali del fornitore. Ho visto diverse persone lamentarsi di loro nel contesto dei plugin Rails di terze parti.

Quindi nel tuo caso, supponendo che questi progetti siano tutti "interni", allora penso che un svn esterno sia un approccio perfettamente valido.

Answer 2

Sono assolutamente d'accordo con la risposta precedente. Dalla mia esperienza di utilizzo di esterni è una soluzione eccellente per i moduli di infrastruttura e le librerie "interne" purché si impostino gli elementi esterni su tag specifici della libreria e non sul suo trunk.

Non ho capito esattamente perché si desidera utilizzare lo spazio di lavoro interamente basato su esterni e non aggiungendo gli esterni direttamente al progetto stesso. Il mio approccio è che qualsiasi progetto che crei su SVN deve essere "built-able" quando è stato estratto.

nel mio approccio repository dovrebbe apparire in questo modo:

/dependencies 
    /xUnit 
      /tags 
       /1.5 
       /1.6 
      /trunk 
    /NHibernate 
      /tags 
       /2.1.0 
       /2.0.1 
      /trunk 
/projects 
    /project1 
      /tags 
       /1.0 
        /sources 
        /xUnit(externals to /dependencies/xUnit/tags/1.5) 
        /NHibernate(externals to /dependencies/NHibernate/tags/2.0.1) 
      /trunk 
       /sources 
       /xUnit(externals to /dependencies/xUnit/tags/1.6) 
       /NHibernate(externals to /dependencies/NHibernate/tags/2.0.1) 
    /project2 
      /tags 
       /1.0 
        /sources 
        /xUnit(externals to /dependencies/xUnit/tags/1.6) 
        /NHibernate(externals to /dependencies/NHibernate/tags/2.0.1) 
      /trunk 
       /sources 
       /xUnit(externals to /dependencies/xUnit/tags/1.6) 
       /NHibernate(externals to /dependencies/NHibernate/tags/2.1.0) 

Answer 3

Se il svn:externals solo riferimento librerie di terze parti, perché non è sufficiente utilizzare un repository Maven/Ivy? Questi sono per il mondo Java e non conosco i loro pendenti .Net ma sono abbastanza sicuro che esistano.

Io uso solo svn:externals per condividere i file antilegi Ant, finché non danno la possibilità di caricarli da un archivio jar.