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
>
>
>


------------------------------------
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.