2010-02-02 11 views
5

Attualmente sto lavorando su un progetto che ha componenti in perl, .NET, C/C++ e Java. Questi componenti sono correlati tra loro, ma non sono legati allo stesso programma di rilascio. A causa dei diversi requisiti dell'ambiente di compilazione/test, il loro inserimento nella stessa gerarchia/bin/src/lib/etc/tests è un po 'ingombrante.Organizzazione di un progetto che utilizza più lingue?

Quali sono alcune buone gerarchie organizzative da utilizzare nel controllo del codice sorgente quando si ha a che fare con un progetto di questo tipo? Attualmente sto appoggiato verso ogni lingua con la propria filiale:

repo/project1/perl/main/...

repo/project1/.NET/main/...

repo/project1/Java/main/...

Come cambierebbe la vostra gerarchia raccomandata se hanno avuto un programma di rilascio vincolato?

+1

Sembra che tu sia sulla strada giusta ... –

risposta

2

Penso che quello che hai esposto è sulla linea. Se si rilascia il progetto nel suo complesso con tutti i componenti anziché rilasciando separatamente ciascun componente, potrei usare svn: esternals in diverse posizioni dei repository o repository completamente diversi, quindi associare semplicemente la build tramite external all'ultima versione tagged compatibile di un componente . Oppure se usi git usa i sottomoduli per fare la stessa cosa.

/repo/project1 
    trunk/ 
    svn:external .Net /repo/project1/components/.Net 
    svn:external perl /repo/project1/components/perl 
    svn:external Java /repo/project1/components/Java 
    -- other integration code or what have you -- 
    tags/ 
    branches/ 
    components/ 
    .Net/ 
     trunk/ 
     tags/ 
     branches/ 
    Java/ 
     trunk/ 
     tags/ 
     branches/ 
    perl/ 
     trunk/ 
     tags/ 
     branches/ 

La struttura esatta dipenderebbe dal flusso di lavoro e dal modo esatto in cui i componenti sono integrati ma si ottiene l'idea.

Problemi correlati