SVN: Il modo migliore per condividere il codice comune tra i progetti

Question

Ho più progetti di siti Web in un singolo repository ognuno dei quali ha una copia di WordPress. Aggiornare WordPress significa aggiornare tutte le cartelle del progetto e conservare copie ridondanti. Questo è utile per i miei script rsync che sincronizzano l'intera cartella. Mi dà anche copie locali del sito completamente funzionanti.

Esistono diversi modi per migliorare questo aspetto e vorrei ricevere un feedback. Sono su Windows e recentemente ho migrato a Subversion.

1. Creare collegamenti simbolici ai bit di WordPress in ciascuna cartella del sito Web. Questo rimarrà in Subversion e Apache. Qualche inconveniente?
2. Avere un'unica cartella WordPress e diramarla negli altri trunk del sito Web. Leggo che i rami sono economici e viene mantenuta una singola copia, ma non sono sicuro che la ramificazione debba essere eseguita su tronchi. Personalmente, penso che questo sia l'approccio migliore. C'è qualche ragione per evitarlo?
3. Infine, è possibile mantenere la struttura corrente e utilizzare uno script per creare copie su tutte le cartelle del sito Web.

Qual è l'approccio migliore e ci sono soluzioni alternative?

Answer 1

Un'opzione sarebbe quella di separare i bit di WordPress in un repository separato (poiché non è realmente parte dei tuoi progetti, è solo qualcosa che usi per costruirli), e quindi usare svn: esternals per recuperarlo nei tuoi progetti nelle posizioni corrette.

Externals Definitions in the SVN book

Answer 2

Si potrebbe aggiungere una punta svn:external definizione al WordPress repository o creare il proprio separato "su misura WordPress Repository" con i plugin e personalizzazioni che si usa.

Answer 3

forse sto solo usando Subversion nel modo sbagliato, ma la nostra struttura di cartelle è simile al seguente

Tronco - Nucleo - Messaging - Applicazione potente eccellente # 1 - Applicazione potente eccellente # 2 - Super Powerful Application # 3

Quindi tutte le nostre app condividono gli stessi componenti Core e Messaging. L'unico lato negativo di questo è che quando le persone si diramano, ottengono tutte le applicazioni, ma questo è più di un fastidio che altro.

Answer 4

Mi capita spesso di riutilizzare le stesse librerie di classi per progetti diversi e nel mio caso preferisco avere una copia separata - freezed per ogni progetto. L'unica ragione è che non voglio rompere progetti a cui non ho lavorato per un po 'nel caso in cui una delle librerie lo supera. Tuttavia, se ogni progetto fa parte di una sorta di progetto principale su cui stai costantemente lavorando, è diverso.

Answer 5

Un modo migliore per eseguire questa operazione è estrarre wordpress in un ramo separato del repository. Quindi, introdurre un file di configurazione in ognuno dei propri siti Web che memorizza il percorso in Wordpress. Puoi aggiungere questa posizione al tuo percorso di inclusione di php. Ecco uno schema:

Questo ha un paio di vantaggi:

• Si può sperimentare con diverse versioni di Wordpress in una sola volta, di fare test e cosa-no.Puoi condividerli tra tutti i siti web
• Non dovrai preoccuparti di dove wordpress è il check-out. Includere una libreria all'interno di un progetto è spesso disordinata, ma questo tipo di configurazione rende più facile mettere le cose in una posizione comune.
• Non è necessario mantenere più versioni della libreria, l'aggiornamento è molto più semplice.

Answer 6

Tradizionalmente, tutto deve essere separato su SVN. Sembra che tu stia usando SVN come mezzo per prendere il codice da diverse aree e unirle insieme.

Quindi stai usando SVN come strumento di costruzione. E 'meglio:

• mantenere i plugin separati
• non conservare wordpress se stesso in SVN, a meno che non si utilizza un ramo fornitore
• quando si ha bisogno di afferrare un app specifica con componenti specifici, il lavoro con costruire-script.

Answer 7

Se si stanno già riunendo tutti i siti in un unico repository, svn: esternal può essere utilizzato per estrarre diverse parti dello stesso repository in vari modi.

E.g. con un repository come

 
repo/site1 
repo/site2 
repo/commonPieces 

È possibile introdurre un "svn: gli esterni" proprietà sul site1 e dirs site2 che dice "commonPieces url-to-repo/commonPieces".

Evitare ovviamente eventuali ricorsioni di loop. Ma questo ha il vantaggio che tutto è nello stesso repository e può condividere la storia - puoi tirare cose che stanno diventando più comuni da site1 o site2 in commonPieces usando "svn copy".

Confronta la nostra soluzione attuale, in cui sto lavorando - migrando roba dai nostri separati repository di progetto in un unico anche-separata repository "corelibraries" perde la storia di sviluppo. Dal momento che noi comunemente sviluppiamo le caratteristiche per un progetto e poi decidere riutilizzarle per, questa perdita della storia accade molto ...

---

Edit: vale la pena ricordare che, mentre "svn update", a site1 aggiornerà automaticamente commonPieces con questa proprietà "svn: externals", un "svn commit" su site1 non mostrerà le cose che sono cambiate in site1/commonPieces. Dovrai effettuare due commit separati, uno da site1 e uno da site1/commonPieces.

Answer 8

Qual è l'approccio migliore e ci sono soluzioni alternative?

di non andare fuori tema, ma vi consiglio di dare uno sguardo duro al git. Facciamo questo genere di cosa giorno dopo giorno con sottomoduli, ed è un gioco da ragazzi.

FYI - migrato da SVN circa 2 anni fa a causa di questo tipo di problemi.