Ho un'installazione multisito di D. che gestisco via CVS. Vorrei sapere se qualcun altro lo fa e quali tag usa.
Io finora ho usato il tag specifico della versione (DRUPAL-5-2, per esempio), solo che poi quando si usa CVS per aggiornare, bisogna specificare il tag diverso per ogni upgrade. Inoltre, manca un po' di coerenza con la cartella in cui, sempre via CVS, scarico i moduli, che in genere hanno il tag della major release (DRUPAL-5).
Ieri sera ho provato ad aggiornare l'installazione portando il tag del core a DRUPAL-5 e nella schermata dei moduli mi risulta di avere non Drupal 5.3, ma Drupal 5.4-Dev (che poi credo coincida a oggi con la 5.3).
Qualcuno ha qualche idea o suggerimento in proposito, soprattutto per pensare di gestire in modo sicure ed efficiente un'installazione del core associata a una selezione di moduli contrib?
in che senso aggiorni con CVS? Sul server hai un deamon che scarica il CVS e copia i file che ti servono nella cartella del tuo sito? mi sembra una pessima idea, preferisco sempre fare gli upgrade a mano, anche perché almeno prima faccio copia di B-U di tutto :)
Ciao
Marco
--
My blog
Working at @agavee
No, nessun daemon almeno per adesso, anche perché comunque dovrei anche automatizzare l'esecuzione di update.php, cosa che richiederebbe un po' di lavoro extra. I B-U li faccio, non ti preoccupare... Il comando CVS lo do a mano collegandomi in SSH al server. E' veramente molto comodo per gli upgrade (ovviamente a patto di non andare a patchare il core). Sul sito di Drupal, d'altra parte, c'è un intera sezione dei manuali dedicata a gestire un'installazione via CVS, solo che non viene indicata una strategia specifica indicata per l'uso dei tag e, soprattutto, per l'interazione tra il core e l'area contrib che contiene i moduli.
Guarda, sinceramente non userei CVS per fare quello che intendi fare tu, in ogni caso (spero che non sia tutta roba già vista :)):
Ma forse non ho capito la tua necessità :|
Ciao
Marco
--
My blog
Working at @agavee
Sì, già visto; grazie lo stesso. Non ti preoccupare, la mia installazione basata su CVS è sanissima (e ovviamente backuppatissima). Il succo del post era chiedere se qualcuno ha delle best practice da consigliare per ottimizzare l'uso di CVS.
Non è un'ottima idea tenere un sito aggiornato via CVS: almeno, non lo è se usi un branch. Molte patch di cui viene fatto il commit possono essere parziali, possono essere insicure, e spesso ci sono più patch che correggono bug di altre patch. Insomma se vuoi utilizzare CVS ti consiglio di farlo sui tag e non sui branch (la versione HEAD del 5.x per esempio). Quando la versione 5.3 (esempio) esce, scarichi il tag 5.3 e aggiorni tramite update.php (se necessario, ma spesso non lo è).
--
Drupal e Siti Web Torino
Blog: Computer Graphics
Ok, grazie. Qualche consiglio su come usare CVS anche per moduli contrib senza incasinare tutto?
Io sto pensando di spostare i moduli contrib in una cartella fuori dal path del core, collegata poi con un link simbolico; non so però se ci siano delle implicazioni negative, non sono molto esperto con CVS.
Scusa non ho capito. Hai una repository locale CVS? Altirmenti in che cosa consiste lo spostamento?
--
Drupal e Siti Web Torino
Blog: Computer Graphics
Sì, faccio il checkout del core e di alcuni moduli contrib selezionati.
Il problema è che dato che i moduli stanno ovviamente in un subpath del core, si crea un po' di casino perché i tag usati da contrib non sono gli stessi; per questo mi piacerebbe poter usare DRUPAL-5 invece di DRUPAL-5-x, perché vorrei scaricare in un colpo solo le versioni stabili del core e dei relativi moduli. Ma questo non è possibile (anche se non capisco perché, come filosofia d'uso del CVS: le patch non testate non dovrebbero andare nel branch ma nel trunk - o HEAD o come diavolo si chiama, così come nel branch stabile del core mi aspetto di trovare solo le versioni stabili, non quelle DEV), e va bene. Allora penso di separare su path diversi le repository core e contrib e di unirle solo con un symlink per far si che funzionino correttamente come "rami" dell'installazione Drupal.
Insomma, se non mi sono spiegato è anche perché non ne capisco più di tanto... ;) Mi piacerebbe solo avere un'installazione da mantenere come aggiornamenti con sforzi ridotti al minimo.
Certamente, le patch non testate non sono neanche committed. Ma può succede che qualcuno si sbagli, e faccia un commit di una patch che verrà sostituita. Per quanto riguarda il branch e l'HEAD, non saprei con esattezza, ma ho sempre visto che nel core (e anche nei moduli che rispettano le specifiche), la versione dev viene fatta nel branch (così da differenziare la versione 5.x-dev, da quella 6.x-dev ad esempio) e i tag pongono i paletti delle release stabili.
Io non lo farei, poi fai tu come vuoi. C'è da aggiungere che a volte alcune patch richiedano un update SQL via update.php. E come fai a saperlo se magari il module.install non è stato ancora aggiornato? Tanti problemi che potrebbero essere semplicemente risolti con un estensione del modulo update-status. Se guardi l10server lo fa già ;)
--
Drupal e Siti Web Torino
Blog: Computer Graphics
Ciao Pinolo, io utilizzo CVS per gestire gli aggiornamenti in locale e fare un upload massivo sul server di produzione solo dopo aver testato il tutto, l'aggiornamento è fatto tramite ssh e sftp, devo ancora ringraziare chi mi ha fatto notare la praticità del tutto :) .. ovviamente questo semplifica molto la gestione degli aggiornamenti ;)
Per la tua situazione io procederei come avevi accennato verso la fine dei tuoi messaggi: tieni il core separato dai moduli di terze parti e dai moduli che sviluppi/modifichi. In questo modo hai la massima libertà di aggiornare solo il core, o ogni modulo ad un particolare TAG. Ovviamente per Drupal resterei solo nei TAG stabili, niente -dev o HEAD. Mentre per i moduli a volte è necessario seguirne qualche sviluppo magari ancora in beta a causa di alcune funzionalità mancanti o personalizzazioni che "stanno per essere integrate" ;)
Ciao!
Grazie a tutti per i suggerimenti, ne farò tesoro e forse rivedrò queste mie policy...