L’arte del check-in
Giovedì 28 Agosto 2008 - 11:00
di Antonio Volpon
Non sto ovviamente parlando del check-in all’areoporto, ma del check-in del codice utilizzando qualche sistema di gestione delle versioni, come per esempio subversion, csv e molti altri.
Secondo Jeff Atwood di Coding Horror sbaglia chi lascia passare troppo tempo prima di riportare il proprio codice all’interno del sistema di gestione delle versioni.
Il rischio è che nel ritardare questa procedura si verifichino dei seri problemi di integrazione delle modifiche. Inoltre, come sostiene Atwood, il codice che non è versionato è come non esistesse.
In azienda tendiamo ad effettuare il check-in abbastanza spesso, circa una volta ogni uno o due giorni. Non è che questo approccio sia comunque privo di insidie, soprattutto quando in molti sono al lavoro sullo stesso progetto.
Chi di voi usa un sistema di gestione delle versioni, come si comporta?
Categoria: PHP e Open Source | Permalink
Commenti
1
purtroppo a volte sono costretto ad apportare piccole modifiche che devono andare in produzione quanto prima quindi mi trovo a fare spesso dei commit.
# - postato da Matteo Galli - 28 Agosto 2008 - 12:22
2
Rilascio delle pagine almeno un paio di volte al giorno.
Al limite si rilascia la pagina e la si riprende immediatamente ma almeno gli altri hanno sempre una versione attualizzata.
Ovvio che se ci sono dei problemi grossi o delle grosse variazioni ciò non avviene.# - postato da LordMax - 28 Agosto 2008 - 12:26
3
In azienda tendiamo ad effettuare il check-in abbastanza spesso, circa una volta ogni uno o due giorni.
Wow… e questo sarebbe spesso? Bisognerebbe fare il checkin massimo una volta al giorno, anzi, ogni volta che un metodo funzionante è completato, anche una volta all’ora o meno.
4
Io non ho mai usato sistemi tipo svn però vorrei usarli, c’è una guida passo passo?
Grazie
5
io uso bzr o git per fare versioning e posso fare check-in quando voglio e ovunque sono questo ha dei grossissimi vantaggi in termini di “quando fare check-in” e si come dice Simone lo faccio tutte le volte che un metodo/classe o un gruppo di metodi/classi sono funzionanti
oltretutto vado sul server di test facendo checkout dal branch di test quindi devo committare per forza per fare test (cioe’ non obbligatoriamente ma quasi)
6
Ci sono diverse scuole di pensiero.
Anche io preferisco integrare frequentemente gli sviluppi nel repository per avere anche una copia di sicurezza.Questo comporta però l’esigenza di stabilire importanti regole di integrità del repository per evitare, ad esempio, che il ramo principale sia reso non funzionante da un commit errato.
Ovviamente, tutto questo discorso non vale se si usa un repository decentralizzato.# - postato da Simone Carletti - 28 Agosto 2008 - 17:23
7
Io faccio commit ogni volta che le modifiche richieste o resesi necessarie, funzionano. Essendo poi unico sviluppatore, il checkout non è strettamente necessario. Perchè uso SVN? Credo sia una necessità adeguarsi a tecniche di gestione dei sorgenti di tipo enterprise, anche se siamo in ambienti decisamente lontani.
Devo dire che da quando ho adottato SVN, Trac e phpdoc, la mia vita di sviluppatore è migliorata parecchio.
Mi dispiace soltanto che non sia possibile usare SVN in modo diretto con Visual Studio Express (mi tocca usare TortoiseSVN).My 2 cents.
# - postato da Luca Gervasi - 28 Agosto 2008 - 18:01
8
Come accennava Simone, c’è la scuola di pensiero che vuole lasciare il trunk funzionante (!= stabile)…
Ne faccio parte, ma da noi ogni sviluppatore lavora in genere su blocchi di codice abbastanza indipendenti e quindi non incorriamo in troppe difficoltà dopo i commit…
in genere…. :)Dovrò informarmi su questi repository decentralizzati… Solo guardati velocemente per ora…
# - postato da Andrea Zilio - 28 Agosto 2008 - 23:03