È una buona idea mettere tutti i progetti nello stesso tronco?

Question

Comprendiamo il difetto ed organizzazione repository svn di solito raccomandato, in caso di avere più progetti, è qualcosa di simile:

root/projectA/(trunk, branches, tags) 
root/projectB/(trunk, branches, tags) 
... 

I nostri progetti hanno un sacco di interdipendenza, e che richiederebbero un uso extense di svn : externals tra di loro, considerando che non facciamo riferimento a dll ai progetti interni, preferiremmo visualizzare il loro codice sorgente invece di lavorare con i binari.

L'utilizzo eccessivo degli esterni, quando si ramificano i repository, la sincronizzazione delle modifiche, può diventare un'esperienza complessa e soggetta a errori, quindi il team non si fidava affatto di questa soluzione.

Quindi un membro del team ha suggerito qualcosa che tutti noi riteniamo possa essere una soluzione migliore: inserisce tutti i progetti nello stesso trunk.

In un primo momento, abbiamo rilevato alcuni problemi con questo approccio, ma nel complesso siamo d'accordo sul fatto che questi problemi si basano su situazioni ipotetiche che molto probabilmente non avremmo mai sperimentato.

Vedete alcuni problemi seri con questa soluzione?

Answer 1

Facciamo questo nella nostra azienda e abbiamo avuto molto successo.

abbiamo 3 directory primarie:

• tag
• rami
• tronco

E poi abbiamo ogni progetto come un sub-directory di quelli.

Tuttavia, a livello di progetto ci si dirige ancora e si utilizza ancora svn: esterni. Ma se avessimo un albero di sorgenti più piccolo dovremmo diramarlo a livello di tronco e non usare svn: extenrals.

È bello poter disporre del trunk di tutti i progetti nello stesso punto. Puoi eseguire il backup, puoi controllare tutto e hai tutte le cose più recenti insieme. Non si perde la posizione unico per tutti i rami, né luogo unico per tutti i tag o perché sono tutti in sottodirectory di/rami/ProjectX e/tag/ProjectX

problemi con svn: externals:

Se i tuoi progetti non sono ESTERNI al massimo, puoi semplicemente escludere l'intero trunk ogni volta ed evitare tutti i problemi con svn: esterni.

Il problema con svn: esterno è che quando si crea un ramo, non crea automaticamente un ramo per ciascuno degli svn: esterni per te. Questo è un problema perché poi nel tempo tutte le tue vecchie filiali non saranno in grado di compilare man mano che il tuo trunk sarà più aggiornato. Un altro problema è che se si effettua una correzione in un ramo su una svn: esterna, tutte le altre branche si interrompono.

Un altro problema con gli svn esterni è che quando si esegue svn: log a livello di root, non si vedono cambiamenti dagli elementi esterni di svn.

Speriamo che un giorno svn esterno sarà risolto per risolvere i problemi di cui sopra, ma fino a quel giorno ramificazione e svn: esterni è un incubo assoluto.

Answer 2

Quello che hai fatto è quello che ho creato nella mia azienda, e viene anche indicato come "layout molto comune" nell'argomento svnbook, Strategies for Repository Deployment.

Niente di sbagliato.

Answer 3

a "mettere tutti i progetti in stesso tronco":

Dalla mia esperienza questa non è una buona idea - perché ogni progetto ha la propria storia e le modifiche e spesso i progetti sono/saranno mantenuti da sviluppatori differenti. Ciò può portare a conflitti - anche se dichiari che attualmente i progetti interferiscono pesantemente.

Quindi perché non si usano tag comuni (con le pietre miliari come nomi) per tutti i progetti per garantire lo stesso codice base e uno script di compilazione, che può controllare i progetti (trunks) automaticamente? È più lavoro, ma come al solito in OOP (capsulazione) preferirei dividere i progetti in directory SVN separate.

Ma: raccogliere un po 'di piccole librerie e app in una directory comune sotto lo stesso trunk non è un problema (vedi "app" e "tools" nel mio esempio qui sotto) - quindi forse "piccoli progetti" possono rimanere nel condiviso/grande baule.

Qui, come ad esempio la mia struttura di directory di SVN:

/projects/ 
/projects/CustomerA/ 
/projects/CustomerA/ProjectX/ 
/projects/CustomerA/ProjectX/trunk/ 
/projects/CustomerA/ProjectX/tags/ 
/projects/CustomerA/ProjectX/branches/ 
/thirdparty/ 
/thirdparty/ExtLibY/ 
/thirdparty/ExtLibZ/ 
/tools/ 
/tools/trunk/ 
/tools/tags/ 
/tools/branches/ 
/apps/ 
/apps/trunk/ 
/apps/tags/ 
/apps/branches/ 

Quindi tutte le cose esterna viene memorizzato in/di terze parti/e tutti interni (progetti, strumenti, applicazioni) hanno le sottocartelle:

/trunk/ 
/tags/  
/branches/ 

... come consigliato nel libro di Subversion e nel post precedente.

Anche se questo sembra un po 'troppo impegnativo a prima vista, ne vale davvero la pena, soprattutto quando il codice aumenta.

Ciao, Chris

Answer 4

vedete alcuni gravi problemi che abbiamo possono avere con questa soluzione?

• La soluzione funziona solo fino a quando si può mettere tutto in un unico repository .

  Ciò significa che l'intero repository deve adattarsi su un singolo disco (o pool di archiviazione) per il prossimo futuro. Considerazioni simili si applicano ad altre risorse del server come la larghezza di banda I/O di rete e disco.

  Suddividere il repository in un secondo momento richiede una grande revisione dell'intero set-up e potrebbe causare mal di testa quando è necessario ricostruire o ramificare le versioni precedenti.

• La soluzione funziona solo se non è necessario limitare le autorizzazioni di lettura/scrittura su una base

  per utente Se è necessario dare lettura/scrittura per projectA, ci troveremo avere per dare il permesso per/trunk/projectA, e/branch1/projectA, e/branch2/projectA ecc.

  La ramificazione diventa quindi un processo pesante che richiede un gran numero di modifiche del permesso. Dì addio allo feature branches.