Re: Organizzare il processo di sviluppo
Luca Bianchi <[email protected]>
| Newsgroups | gmane.comp.cms.cold-fusion.devel.italian |
|---|---|
| Message-ID | <6600427851082076997@unknownmsgid> |
Sent from my iPhone On 08/giu/2012, at 15:49, "massimo-AWCe33ycjKG6CeScpoWb4QC/[email protected]" <massimo-AWCe33ycjKG6CeScpoWb4QC/[email protected]> wrote: >> si, se il file system si perde i pezzi. > > Lo hai visto succedere? Con quale sistema accedevano al server? Si, l'accesso era peró svn+ssh su una centos. Non ricordo cosa fosse il file system. Facendo un commit si è interrotta la connessione e si è corrotto il repository. Ho dovuto ripristinare da un backup, perdendo l'ultima giornata di commit di un collega. > Non riesco > a crederlo possibile se si usa HTTP o il protocollo SVN. Se si accede > direttamente via file system in piú di una persona, credo possa succedere, > ma nessuno dovrebbe usare accesso diretto se non lavorando da solo. > > > >> E comunque sei nelle canne se muore il server.. > > Questo vale anche per il db server e via discorrendo, i back-up servono a > prescindere da SVN o Git. > Si, ma comunque almeno alcune ore di lavoro vanno perse > > >> probabilmente se non hai esperienza è più ostico git di svn, ma >> considerando il fatto che raramente si è propensi a cambiare il tool di >> versioning, è difficile che uno parta con uno poi faccia di sua spontanea >> volontà ad un altro tool > > Sto usando Git con un team di 4-6 persone da oltre un anno. Posso dire che > Git risolve alcuni problemi meglio di SVN, peccato peró che sono tutti > problemi che non abbiamo :-) Mi piace Git per alcuni motivi: - essendo i commit piú veloci, tendi a fare commit piú piccoli e numerosi - creazione e merge dei branch, da linea di comando è rapidissimo, quindi come metodologia ti abitui piú facilmente a lavorare per feature/esperimenti su molti branch di cui fai push solo quando ti rendi conto che servono, se no rimangono in locale - puoi gestire progetti annidati con i submodule, avendo diverse linee di sviluppo per diversi moduli - de-gittizzare un progetto è molto semplice - puoi avere piú server di repo: ad esempio, noi facciamo push su un repository, che fa riferimento allo stage e solo quando ci sono tag ne viene fatto push in sul repo di produzione (pubblico) Poi ci sono anche cose per persone molto più zen di me che periodicamente fanno un rebase andando a sistemare la storia del progetto legando determinati file a determinati commit. Infine una cosa come lo Cherry Pick dei commit, permette di recuperare ed applicare solo alcuni commit, selezionando le feature Ti diró che da quando lo uso mi è piú facile lavorare meglio. Non è una cosa che non potessi fare prima, ma se non sei troppo zen, piú è facile e piú sei invogliato a farlo > > Massimo > > > ------------------------------------ > > CFMentor > http://www.cfmentor.comLink utili di Yahoo! Gruppi > > > ------------------------------------