Come granulare sono i tuoi "progetti" svn:. Un unico grande progetto che contiene diverse applicazioni releated o di un "progetto' per app

Question

definisco un progetto come directory SVN contenente tronco, i rami, i tag sub dirs

quali criteri usi quando determini quando dividere un progetto in due o consolidare più progetti in uno? - Un'unica applicazione per "Progetto" con progetti condivisi per fonti e risorse comuni? - Un grande "progetto" contenente tutte le fonti e risorse per l'app?

Un singolo progetto o più progetti hanno entrambi i loro vantaggi e svantaggi. verso un singolo progetto e sto cercando di capire se questo è l'approccio giusto.

I progetti divisi consentono una maggiore capacità di controllare in che modo le diverse parti della suite incorporano un cambiamento. La libreria comune può essere versione e diverse applicazioni possono scegliere di utilizzare una versione specifica (approccio di gestione dep di maven).

Il progetto diviso crea anche più gerarchie di classi, rendendo il codice più difficile da comprendere nel suo complesso e potenzialmente portando alla duplicazione del codice. Assumerei che la corretta progettazione della struttura generale e le relazioni tra i componenti sarebbe la chiave per gestire questo costo.

Un approccio di progetto unificato renderà più semplice lo sviluppatore in termini di impostazione di uno spazio di lavoro e fornirà una singola gerarchia di classi. Questa è un'arma a doppio taglio in quanto getterà anche molte più informazioni allo sviluppatore (troppe classi da comprendere).

Quindi, quando si sta tentando di decidere dove combinare e dove dividere, quali regole si usano?

Answer 1

Grazie per l'input. Non voglio "scegliere" una risposta perché penso che tutti abbiano dei punti preziosi in loro. Evitare l'ottimizzazione prematura sembra fondamentale così come mantenere il layout il più semplice possibile per il momento. Stiamo passando a un singolo progetto contenente le app perché il 90% delle volte rilasciamo ALL insieme. Pertanto, complicare le cose con una app per progetto non sembra avere senso. Anche quando andiamo a farlo, è probabile che tutti gli artefatti di Maven per una determinata versione vengano creati dallo stesso ramo. Possiamo sempre cambiarlo in seguito, se necessario, usando la cronologia SVN e il fisheye per mantenerci sani di mente.

Rifatteremo il layout di origine proprio come faremo con il refactoring della sorgente. Quando un progetto inizia ad "annusare male" da una situazione di circonferenza e dipendenza lo suddivideremo, ma non prima. Probabilmente userò la circonferenza in tempo, non la circonferenza nello spazio: il tempo di costruire il test &, il tempo per il checkout. Se ho un albero da 1 GB che posso effettuare il checkout in < 10 minuti e creare/test in < 30 minuti, non ho davvero bisogno di romperlo a meno che non mi venga richiesto di rilasciarne frequentemente parti.

Quindi, grazie per l'input. È stato davvero utile nel formulare la domanda per me squadra e valutare le opzioni.

Answer 2

Uso progetti separati e li combino per formare una soluzione tramite svn: esterni.

Answer 3

Il SVN Book ha una buona discussione su entrambi gli approcci.

Alla fine sceglierei qualsiasi cosa sembrasse più naturale per gli utenti del repository.

Personalmente, ho preferito un singolo approccio trunk/tag/rami SVN con tutti i miei progetti di codice effettivi nelle proprie cartelle all'interno di quelli.

Tuttavia, per una base di codice più ampia (ho gestito solo 3-4 piccoli progetti che facevano parte di una singola soluzione), prenderemmo in considerazione la possibilità di passare a un approccio diviso.

Answer 4

Abbiamo inserito tutti i progetti relativi a una singola app in un SVN Rep, semplicemente per semplificare la manutenzione, centralizzando la base di codice dell'app in un unico repository e anche la capacità di gestire le interdipendenze tra le diverse risorse dell'app.

generalmente categorizziamo le nostre risorse in diverse cartelle nel bagagliaio. tale categorizzazione si basa principalmente sul raggruppamento funzionale/modulare o sul raggruppamento a livelli [DAL, BLL, GUI, ecc.]. questo è completamente fino a come hai strutturato il codice. Spero che questo ti aiuti.

Answer 5

Uso entrambi progetti separati e progetti combinati in base alle dimensioni del progetto. Per i nostri progetti di grandi dimensioni, ognuno si trova in un repository separato e ha procedure di compilazione e implementazione indipendenti. Per i nostri progetti più piccoli abbiamo un repository "tools" per contenerli, con ogni sotto-progetto come sottodirectory della root.

Inoltre, gestisco un repository "personale" in cui le persone possono archiviare i programmi di test di utilità una tantum o altre cose che potrebbero trarre vantaggio dal controllo del codice sorgente e dai backup centralizzati, ma non appartiene come progetto indipendente.

Answer 6

Un'app/modulo distribuito in modo indipendente per progetto. L'utilizzo di un singolo progetto rende difficile introdurre cicli di rilascio se si scopre che è necessario avere una gestione delle dipendenze Maven -ish con un modulo in base alle implementazioni stabili di altri moduli. Può anche portare le persone a utilizzare il codice casuale dall'aspetto utile da altre app direttamente invece di estrapolarlo per mantenere il grafico di dipendenza Sane (tm).

Si consiglia di eseguire test di integrazione utilizzando le corrette suite di test e le pratiche di CI definite chiaramente, non affidandosi a metà del proprio errore in caso di interruzione improvvisa di una parte.

Un altro problema con un singolo progetto uber è che è piuttosto oneroso per gli utenti git-svn che funzionano solo su un singolo modulo.

Answer 7

Conservare repository SVN separati per progetti separati. L'ultima cosa che vuoi è avere un Merge Day

Answer 8

Crescere in modo organico. La pre-ottimizzazione è la radice di tutti i mali, ha detto Dijkstra. Tieni a mente anche YANGI (non ne avrai bisogno).

Ogni applicazione ha una propria cartella con trunk/tag/rami. Se un progetto all'interno di un'applicazione diventa molto grande, viene spinto nella sua cartella separata e può essere collegato all'applicazione in fase di compilazione (o anche in svn: esterni).

Detto questo, se i requisiti del tuo progetto sono di sviluppare un'applicazione complessa scritta da 10 sviluppatori e tu sei il gatekeeper o il master di costruzione, puoi prendere in considerazione alternative più complesse.

Answer 9

Si potrebbe voler verificare Subversion revision number across multiple projects.

Answer 10

non c'è una risposta "buona" qui, ma penso che ci dovrebbe essere una distinzione tra repository SVN che contengono 1 o 2 progetti e altri che contengono 100.

Gestisco un repository SVN che è stato migrato da VSS, ha diverse centinaia di "progetti" in esso, nessuno di essi è stato organizzato lungo la struttura trunk/branch/tag (infatti ritengo che la struttura sia davvero superflua e inutile dopo aver usato SVN per un po ', certamente non aiuta quando si taggano 2 o 3 progetti come una singola modifica).

Manteniamo una directory di progetto per tutti i nostri software mantenuti, in quanto abbiamo sottodirectory per la configurazione e un'altra per la sorgente. Sotto a quelli abbiamo i numeri di versione del prodotto - così efficacemente stiamo gettando via il concetto di trunk, abbiamo solo le directory dei tag - il numero più alto è il trunk (dobbiamo farlo perché dobbiamo supportare diverse versioni dei progetti contemporaneamente). L'unione avviene quando necessario, quindi se aggiorno un bug nel progetto A, versione 3.0; Unirò quelle modifiche alla versione 4.0 e alla v5.0.

Se dovessi fare un repo con solo 1 o 2 progetti, potrei essere tentato di mantenere la struttura di tag/ramo, ma d'altra parte - probabilmente manterrei le directory esplicite nell'albero principale (assumendo Non ho rilasciato abbastanza spesso da taggare regolarmente) (uso il numero di revisione come 'tag' BTW, e memorizzo i binari lì. Quindi se ho bisogno di ottenere una particolare revisione precedente, posso prendere il giusto binario dall'aspetto al registro)

È sorprendentemente facile da gestire considerando che ho un repo da 10 Gb con un revnum attualmente oltre 300.000 con tanto di vecchio codice in là e più recente. Consiglierei la struttura agli altri e la userò di nuovo.

Incidentalmente, un altro motivo per cui tag dir non funzionerebbe per noi è perché rilasciamo ogni volta che c'è un bug o una richiesta di modifica, non importa quanto minuscola. La nostra directory di tag sarebbe ingestibile dopo un po ', questo è il motivo per cui usiamo il revnum come tag - possiamo associarlo al bug tracker per renderlo più leggibile anche dall'uomo.

Quindi, per riassumere in ruvida, abbiamo una struttura di directory come questo dove v1 e v2 sono versioni del prodotto:

maint/source/v1.0/projectA 
maint/source/v1.0/projectB 
maint/source/v2.0/projectA 
maint/source/v2.0/projectB 
etc 

ovviamente, potremmo mettere un dir ramo sotto 'sorgente', e un ramo/tag anche sotto ogni sottoprogetto, ma ciò diventerebbe complicato se avessimo bisogno di rilasciare 2 sottoprogetti come una singola richiesta di modifica (come facciamo abbastanza spesso). Mettere un tag sottodir sotto la dir sorgente significherebbe taggare tutto, quando viene modificato solo un singolo sottoprogetto (non si adatta al nostro requisito di tenere traccia di ogni sottoprogetto singolarmente)