Se avessi utilizzato prima SVN nello sviluppo di siti…
Venerdì 13 Giugno 2008 - 09:14
di Simone Carletti
- Avrei evitato di rinominare pagine default.old.php, default.old3.php, default_non_usare_mai.php solo per tenere memoria dei cambiamenti;
- avrei impiegato meno della metà del tempo per l’invio dei cambiamenti online via FTP. Un semplice
svn upo eventualmentesvn checkoutavrebbe degnamente svolto il compito per me; - avrei potuto modificare qualsiasi file in tempo reale da qualsiasi postazione, anche internet point, in pochi click;
- non avrei dovuto preoccuparmi di inviarmi via email le modifiche fatte su un altro computer, solo per tenere aggiornato il mio backup di casa;
- non avrei dovuto dare un accesso FTP al grafico per correggermi dei template, sarebbe bastato abilitargli il checkout della cartella che desidero ed avrei potuto tenere uno storico degli aggiornamenti;
- non avrei dovuto decomprimere 5 Gb di backup solo per scoprire che la cartella che mi serviva, pubblicata il 24 Novembre 2003, per qualche motivo non è in nessun backup;
- avrei impiegato meno di 30 secondi, il tempo di un
svn statusosvn diff, per capire quale delle copie sui 3 computer che uso è la più aggiornata; - non avrei dovuto mettere offline 4 ore un sito per ripristinare il backup del forum, aggiornato per sbaglio ad una versione non compatibile con il mio server;
- avrei potuto fare molto di più, in molto meno tempo!
In realtà uso SVN (prima) e sistemi distribuiti per la gestione del codice (ora) da molto tempo ma, come tutti quelli che si fanno le ossa da soli, i miei primi progetti erano gestiti con il vecchio metodo della copia locale e copia remota, con sincronizzazione manuale in FTP.
Sono certo che ancora molti, troppi utenti (e clienti! garantisco…) adottano questo sistema del tutto improduttivo. Confermate?
Se veramente volete lavorare con una marcia in più, passate ad un sistema di gestione del codice. Le applicazioni sono numerose. Potete tenere sotto controllo la vostra home folder come backup (fatto), la cartella degli articoli che inviate al vostro editore (fatto), i siti che gestite (fatto) e molto altro ancora (suggerimenti?).
Categoria: Software e Servizi | Permalink
Commenti
1
- Avresti potuto recuperare una qualsiasi versione di un file versionato (molte volte il cliente richiede modifiche sostanziali a parte del materiale e poi, dopo qualche settimana, rivuole la versione originaria) :)
Da più di un anno, su qualsiasi progetto che preveda più di una settimana di sviluppo, utilizzo SVN per il versioning dei file. E da allora dormo sonni molto più tranquilli. Sarei curioso di provare mercurial prima o poi.
# - postato da Fabrizio Calderan - 13 Giugno 2008 - 09:36
2
tutto quello che dici è verissimo! è più di un anno che dico di farlo e ancora sono a rinominare i file in .old… la mia è solo pigrizia di imparare una cosa utilissima per uno sviluppatore! a dire il vero qualche volta ho usato svn ma con poca consapevolezza..cerco sempre qualcuno che me lo possa insegnare meglio di quanto possa apprendere su qualche libro o guida (..ho letto anche quelle 2 di html.it..)
3
Esiste una buona guida a SVN online?
E’ vero, a volte per pigrizia non si imparano cose necessarie.
4
http://svnbook.red-bean.com/ è la migliore risorsa.
# - postato da Simone Carletti - 13 Giugno 2008 - 10:23
5
Avrei evitato di rinominare pagine default.old.php, default.old3.php, default_non_usare_mai.php solo per tenere memoria dei cambiamenti;
… moltiplicalo per n, ridicolizza i nomi per y e ti rendi cosa rischi quando ti è richiesta una consulenza SEO :D
# - postato da Simone Rinzivillo - 13 Giugno 2008 - 10:54
6
- invece che semplicemente rinominare un file .old avresti lottato con una nuova tecnologia
- avresti dovuto trovarti un altro hosting che supportasse svn o noleggiare un server
- avresti lottato per insegnare ad un grafico e a tutti i colleghi che a malapena conoscono l’FTP un nuovo modo di lavorare
in realtà è solo invidia! SVN, aspettami che arrivo anch’io! ;)
7
non avresti (avrei) dovuto passare 10 minuti di assoluto panico per un file corrotto mentre stavi per mettere online l’ultima versione sel sito col cliente davanti…
non avresti (avrei) avuto tanti problemi a lavorare in team con le versioni dei file da controllare a mano x capire se stai aggiornando una copia obsoleta.
Non so ancora abbastanza dei sistemi distribuiti ma Subversion (in accoppiata con TortoiseSVN) ha tutto quello di cui si possa aver bisogno per risolvere tutti i problemi sopra, quindi usatelo!
@Luigi: io ho imparato da questo libro on line, svnbook
8
beh però appena si va sviluppo distribuiti meglio GIT…
# - postato da Andrea Paiola - 13 Giugno 2008 - 12:07
9
svn, git ed il vecchio cvs (problemi di porting di vecchi progetti ancora attivi. E pigrizia, certo) qui.
Il problema é che occorre un versioning sistem duttile per tutti gli elementi della UI grafici e un supporto maggiore per i files disparati (files bundles su OS X, ad esempio).
A mia conoscenza vi é per i primi Alienbrain che é costosetto e, se si usano prodotti Adobe, Version Cue. Per i secondi vi sono problemi ad individuare un modello capace di essere efficace.Suggerimenti?
# - postato da semioticmonkey - 13 Giugno 2008 - 14:31
10
Io prorpio in questo periodo sto passando a questi sistemi in maniera sistematica…. (come parlo…)
Davvero usi svn per la tua Home?
11
Se avessi da sempre usato git o mercurial avrei evitato tutti i problemi distributivi di svn
# - postato da Oscar Del Ben - 16 Giugno 2008 - 07:45
12
Salve a tutti. Vorrei utilizzare SVN in una infrastruttura formata da un server web (PHP/MySQL) di sviluppo che fa anche da server SVN e da 3 programmatori che hanno la necessità di vedere le modifiche apportate al codice NON sul proprio PC ma sul server web quindi i vari commit devono essere subito visibili sul server web…
Qualcuno sa dirmi quale sia la soluzione migliore?
Vi ringrazio anticipatamente.
13
Ciao Gianluca,
l’idea di mettere immediatamente in produttività il risultato di un commit non è molto saggia.Ad ogni modo, se questa è la tua esigenza, ti consiglio di procedere come segue:
1. crea il repository
2. esegui un checkout del repository sul server web in modo tale che il virtual host punti ad un checkout del repository stesso.
3. ora hai 3 scelte. O crei uno script che via crontab vada in automatico ad eseguire l’update della working copy associata al virtual host ogni X minuti, oppure deleghi l’update a mano o ancora usi le funzioni di post commit di subversion (una specie di callback) per lanciare lo script di update ogni qual volta viene eseguito un commit al repository centrale.Per tentare almeno di arginare parziali pericoli, ti consiglierei di definire un ramo nel repository che corrisponda alla versione pubblicata (se non la trunk, allora una branch specifica) ed eseguire il checkout di quest’ultima, poi collegandolo al virtual host come prima indicato.
# - postato da Simone Carletti - 06 Agosto 2008 - 17:39