2012-07-06 16 views
12

Ho qualche problema a lavorare con zf e git in un progetto piuttosto grande. L'applicazione zf ha circa 20 moduli e per il momento tutto è memorizzato in un unico repository git. Quindi quando esegui il checkout dell'applicazione, esegui il checkout dell'intero set di moduli, fogli CSS, file js, ecc.Utilizzo di zend framework e git nei progetti di grandi dimensioni

Quello che vorrei fare è qualcosa come in wordpress o drupal: hai la tua applicazione principale e per ogni modulo hai un repository git separato che controlli nella directory dei moduli. Dopo il checkout, ci lavori e poi lo impegni. Ma con zend non puoi farlo perché i file multimediali (css, js, images) sono memorizzati in una directory diversa in/public (ogni modulo può avere i propri file css, js in/public/_MODULE_NAME_/css per esempio). Sto lavorando in/application/modules /.

Quindi la domanda è: come si lavora con le applicazioni modulari zend framework e git?

+3

È sempre possibile inserire le risorse statiche (CSS, JS, ecc.) Nella directory del modulo e copiarle in 'public' come un'attività di compilazione o creare collegamenti simbolici in' public' – Phil

+0

mi sembra un problema simile una volta aveva: http://stackoverflow.com/questions/6680768/how-do-i-organize-my-git-repo – eckes

+0

In ZF2 i moduli sono completamente indipendenti, possono essere collegati come sottomodulo (repo completamente separato), ma in ZF1 con la sua struttura data non è possibile. – bedeabza

risposta

2

Io di solito riesco a far fronte con una configurazione di soft link, avendo un progetto super in webfolder e un collegamento simbolico i moduli da una cartella diversa in:

* SuperProject/ 
    + application/ 
    + ModuleA --> ../../Modules/ModuleA/application 
    + ModuleB --> ../../Modules/ModuleB/application 
    + config/ 
    + views/ 
    + layouts/ 
    + public/ 
    + ModuleA --> ../../Modules/ModuleA/public 
    + ModuleB --> ../../Modules/ModuleB/public 
    + css/ 
    + js/ 
    + library/ 
+ Modules/ 
    * ModuleA/ 
    + application/ 
     + config/ 
     + views/ 
     + models/ 
    + public/ 
     + css/ 
     + js/ 
    * ModuleB/ 
    + application/ 
     + config/ 
     + views/ 
     + models/ 
    + public/ 
     + css/ 
     + js/ 

Le directory stellati sono repository, il SuperProject/pubblico è il punto di ingresso per il server http (ovviamente con i collegamenti simbolici abilitati). Ovviamente non aggiungi alcun file di modulo nel tuo repository SuperProject, ma solo le modifiche nelle directory globali (ad esempio application/config /) - nella migliore delle ipotesi, ignori i moduli attraverso il file .git_ignore. Poiché questo metodo si basa su collegamenti simbolici, funzionerà solo su sistemi unixoid. Pur non essendo perfetto, è il minimo problema.

+0

relativo ai collegamenti simbolici: potrebbe funzionare su Win32 con giunzioni (http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx, http://en.wikipedia.org/wiki/Symbolic_link # NTFS_Junction_points)? – eckes

+0

@eckes potrebbe funzionare, non l'ho ancora provato. Ma da una rapida ricerca, sembra implementare la stessa funzionalità di un symlink unixoid. Hai un sistema Windows per testarlo? – Lars

+0

solo XP. E la cosa davvero interessante (i link simbolici NTFS che supportano anche i file, non solo le cartelle, http://en.wikipedia.org/wiki/NTFS_symbolic_link) non funzionano lì ma hanno bisogno almeno di Vista. – eckes