Cosa fare con più progetti a seconda della stessa fonte?

Question

Questo è qualcosa che ho incontrato due volte nel mese scorso e non sono nemmeno sicuro di come si può dire come una query di Google.

In realtà sto utilizzando SVN per tutto questo, ma sembra che questo dovrebbe essere un problema di controllo generale delle versioni.

Abbiamo due progetti e uno di questi dipende da un altro codice. A causa di problemi API, non è pragmatico avere una qualche forma di collegamento tra i prodotti (e non voglio dover configurare tutte le macchine dei non codificatori per fare in modo che funzioni).

Immagino che se metto una copia del codice condiviso nella struttura della directory, finirò per sovrascrivere tutti i file di configurazione che SVN usa. Ciò significherebbe che la versione nelle directory del progetto dipendente non sarebbe più in grado di aggiornare.

Es:

progetto # 1 ha bisogno di usare il MyExampleClass di classe, però, MyExampleClass è qualcosa che viene definita come una parte del bisogno e da Project # 2.

Answer 1

Guardare in svn:externals

Answer 2

Mettere tutti i file condivisi in una cartella separata in uno dei due progetti o in una separata. Quindi utilizzare externals per fare riferimento a tale cartella. Non è una buona idea mescolare file da posizioni diverse nella stessa cartella.

Answer 3

svn: gli esterni consentiranno di portare i file a livello di directory. Come:

Proj1\ 
    File1 
    File2 

Proj2\ 
    File3 
    File4 

Poi nel Proj2 si può svn: esterni Proj1, e finire con:

Proj2\ 
    Proj1\ 
    File1 
    File2 
    File3 
    File4 

Ora, se si vuole avere file da 2 progetti in 1 cartella come:

Proj2\ 
    File1 <- from Proj1 
    File2 <- from Proj1 
    File3 
    File4 

Quindi non credo che SVN lo supporti.

Tuttavia, ho lavorato con altri strumenti di controllo del codice sorgente che consentono di "collegare" un singolo file da un progetto a un altro ovunque si desideri (Borland StarTeam in particolare).

Answer 4

Abbiamo utilizzato svn:externals indicando il codice condiviso in pratica da alcuni anni. Abbiamo avuto alcuni problemi interessanti che probabilmente dovresti prendere in considerazione prima di usarlo. Qui è la struttura che abbiamo:

root 
+---common 
| +---lib1 
| | \---trunk 
| |  +---include 
| |  \---src 
| \---lib2 
|  \---trunk 
|   +---include 
|   \---src 
+---proj1 
| \---trunk 
|  +---include 
|  | \---common 
|  \---src 
|   \---common 
\---proj2 
    \---trunk 
     +---include 
     | \---common 
     \---src 
      \---common 

I common directory in entrambe le include e src in un progetto contengono definizioni esterne che tirano nelle librerie comuni:

c:\dev> svn pget -v svn:externals proj1\trunk\src\common 
Properties on 'c:\dev\proj1\trunk\src\common': 
    svn:externals : lib1 http://.../common/lib1/trunk/src 
        lib2 http://.../common/lib2/trunk/src 

Il problema che abbiamo corriamo in è multiforme ma correlata al tagging e alla ramificazione della nostra fonte mentre i progetti cambiano nel tempo. La definizione esterni che ho mostrato sopra ha alcuni problemi abbastanza gravi se si vuole avere riproducibili costruisce:

1. Si riferisce ad un target dinamico - trunk.
2. Non si riferisce a una revisione esplicita.

Quando si dirama utilizzando svn copy, gli esterni vengono copiati letteralmente poiché sono in realtà solo proprietà associate all'oggetto. Alcuni degli altri comandi svn (commit, checkout e export) interpretano effettivamente le proprietà. Quando tagghi un progetto, vuoi davvero conservare lo stato del progetto per tutto il tempo. Ciò significa che devi "appuntare" gli elementi esterni a una revisione specifica, quindi devi cambiare la definizione degli esterni per fare esplicito riferimento alla revisione che desideri (ad es.,). Questo risolve un aspetto del problema.

Se è necessario mantenere più rami incompatibili del codice comune, è necessario specificare quale ramo si desidera esplicitamente insieme (eventualmente) alla revisione.

Inutile dire che questo può essere un po 'di mal di testa. Fortunatamente qualcuno là fuori in Subversion land scrive lo script svncopy.pl che automatizza parte di questo pasticcio. Siamo ancora (e abbiamo lottato) con alcune delle difficoltà a sostenerlo in un prodotto distribuito sul campo con un mucchio di codice condiviso e un mandato di tre diverse versioni sul campo in qualsiasi momento.

Se si segue questa rotta, assicurarsi di considerare come verranno mantenuti i collegamenti man mano che i progetti aumentano e cambiano. Abbiamo scoperto che un po 'di tempo a pensare a un processo sarà molto importante qui.

Answer 5

Esterni, ma non essere a conoscenza di questo problema:

Subversion update externals to a date