svn + drupal

Io lavoro al contrario, non è canonico, ma è il modo che ho trovato più comodo:

• Tutti lavorano sul trunk
• Alle varie relase si fanno dei branch e vengono tenuti stabili questi, su cui vengono fatti i diversi bugfix.
• Ogni rilascio in produzione dei bugfix viene taggato

Per farti un esempio, progetto MIOPROGETTO, ho:

ripeto, è una mia convenzione, che presto modificherò (spero) in favore di una maggiore frammentazione dei repo ed un uso più massiccio di feature/drush/drush-make.

Ciao, visto che anche drupal.org si è spostato su git perché non Lo usi anche tu?

Felagund wrote:

ignoro feature/drush/drush-make :(

Male, MALISSIMO :)

Scherzi a parte, se hai un attimo di tempo guardateli, rivoluzionano il modulo di lavorare su progetti di una certa entità e con team distribuiti.

Felagund wrote:

su trunk avresti un'installazione compelta di drupal, dico il cms + eventuali sites/ (con moduli third e custom) + eventuali profiles, giusto? tutti lavorano là e committano quando dovrebbero farlo.
i file di configurazione, che si differenziano per host (alludo a settings.php, .htaccess, l'aggiunta di php.ini su aruba, config.php di FCKEditor), hanno le versioni base "vergini" fresche di installazione insieme a diverse copie file in base all'host di destinazione ipotizzato se queste esistono (ad esempio aruba.php.ini, aruba.htacces, aruba.settings.php) e, infine, le copie locali di ognuno per poter testare quanto fatto, magari dando a questi file i nomi corretti (per poter esser visti dal cms) e dando loro il comando svn:ignore, il tutto nella trunk. È corretto?

Felagund wrote:

I branch delle varie release contengono tutto il progetto, installazione compresa? Se si, composto in questo modo, un repository non diventerebbe troppo grosso?

Diciamo che il repository cresce, ma hai l'enorme vataggio di poter ripristinare tutto esattamente come era effettivamente, senza possibilità di dimenticarti dei pezzi, il che ti può salvare in certe situazioni. Tutto sta nel trovare quale sia per te il vantaggio maggiore.

Felagund wrote:

Correggimi se erro.
Se io ho MIOPROGETTO-1 e MIOPROGETTO-2, ciò significa che ho due versioni del progetto, le cui funzionalità potrebbero variare. Se entrambe le versioni sono attive, come si fa a lavorare su trunk per entrambe?

Esatto, non lavori sul branch una volta che hai devinito e ottenuto una milestone che ritieni sufficientemente stabile da poter essere separata dal trunk. Ovviamente non è bellissimo, perché comporta di lavorare parallelamente su due ambienti, ma permette di portare avanti funzionalità per le relase successive (sul trunk) con eventuali bugfix e stabilizzazioni che devono essere fatte sul ramo che stai per mettere in produzione (o che è già in produzione).

Felagund wrote:

Oppure per

mavimo wrote:

Alle varie relase si fanno dei branch e vengono tenuti stabili questi, su cui vengono fatti i diversi bugfix.

intendevi che i bugfix li fai direttamente sul branch, per poi taggarlo come MIOPROGETTO-1.x++? Indi se è così - sempre correggimi se erro -, su trunk si lavora alla prima alpha di una nuova versione del progetto; giusto?

Si, diciamo che grossomodo è così. Il problema diventa quando NON hai bene idea di cosa deve finire in ogni branch (che poi sono le diverse versioni del sito), mentre i tag più o meno sono le milestone che finiscono in produzione. Un enorme svantaggio è che ogni tanto devi fare i salti mortali per mergiare trunk e branch (per esempio quando risolvi un bug sul brunch in produzione poi devi portarlo anche sul trunk, dove magari altri hanno lavorato refattorizzando la funzionalità, quindi... :/

Felagund wrote:

ziobudda wrote:

Ciao, visto che anche drupal.org si è spostato su git perché non Lo usi anche tu?

git è un altro server di versionamento?

Si, GIT è un altro server di versionamento in cui cambia molto la logica, sono praticamente tutti branch, non esiste un trunk (ma esiste un branch master), con una serie di logiche di uso diverse (per cui probabilmente lo schema sopra indicato perde di significato).

@ziobudda: ci sono casi in cui non puoi scegliere il sistema di versioning, o non conviene cambiarlo (git ha una curva di apprendimento non banale, se tutti i dev conoscono SVN e il progetto è alle porte conviene usare quello :) )