Stampa

Effettua l'accesso o una nuova registrazione.
1 ora 1 giorno 1 settimana 1 mese Sempre
Inserisci il nome utente, la password e la durata della sessione.

[StM]

Da quando ho cominciato a lavorare (5 anni fa) ho sempre cercato di introdurre le meraviglie di un qualsivoglia version control system collaborativo, ma quando è stato deciso di usare CVS (e io ero contento, meglio di niente) lo si è usato come mero contenitore di backup in cui ciascuno faceva le proprie commit separatamente (e allora sono stato molto meno contento). Con grande fatica sono riuscito a introdurre l'idea che non è vietato fare il checkout dal progetto di un altro, ma quanto alla commit è tutta un'altra storia.

Ora può essere che con l'anzianità mi diano un po' più retta (anche se paradossalmente sulle cose nuove si tende a dare più credito alle facce nuove e non a chi è lì da anni e ormai lo si crede fossilizzato in un ruolo specifico), e salvo contrordini cercherò di creare tutta una serie di pappe fatte per usare con successo Mercurial, anche se so già che in pochi si impegneranno per capirne il funzionamento e usarlo propriamente. Piuttosto si perdono le giornate dietro a problemi triviali, ma guai cambiare il metodo di lavoro.

Voi che esperienze avete avuto in proposito (che potete raccontare)?

[Id]

Da quando ho cominciato a lavorare (5 anni fa) ho sempre cercato di introdurre le meraviglie di un qualsivoglia version control system collaborativo, ma quando è stato deciso di usare CVS (e io ero contento, meglio di niente) lo si è usato come mero contenitore di backup in cui ciascuno faceva le proprie commit separatamente (e allora sono stato molto meno contento). Con grande fatica sono riuscito a introdurre l'idea che non è vietato fare il checkout dal progetto di un altro, ma quanto alla commit è tutta un'altra storia.

Ora può essere che con l'anzianità mi diano un po' più retta (anche se paradossalmente sulle cose nuove si tende a dare più credito alle facce nuove e non a chi è lì da anni e ormai lo si crede fossilizzato in un ruolo specifico), e salvo contrordini cercherò di creare tutta una serie di pappe fatte per usare con successo Mercurial, anche se so già che in pochi si impegneranno per capirne il funzionamento e usarlo propriamente. Piuttosto si perdono le giornate dietro a problemi triviali, ma guai cambiare il metodo di lavoro.

Voi che esperienze avete avuto in proposito (che potete raccontare)?

Io ho usato:
- Visual SourceSafe (che non ha la gestione della concorrenza - se due committano insieme si sfascia il database intero )
- svn (che non e' male, ma versiona "un po' cosi' " i file binari, ha una gestione del merge terribile, non ha branching - lo simula con la copia, ma poi come fai i merge? - e non ha una UI "propria", anche se ci sono dei tool third-party, come Tortoise).
- Alienbrain (non e' terribile, ma a volte fa cose strane).
- Perforce (che e' il tool di scc piu' bello che io abbia mai usato, funziona bene sempre e per tutto).

Mercurial e git... non so - gli scc distribuiti non mi piacciono.
Mentre ne comprendo il senso, l'utilita', e la filosofia (che e' buona), non c'ho proprio voglia di star dietro alla bega dei commit in locale, e poi da locale al repository, e poi questo l'ho committato in locale e sul repository locale di quell'altro pero' sul repository "centrale no", e A ha bisogno di questo che ha bisogno del commit di B che pero' e' legato al commit di C e via.
A sensazione, finisce che si passa piu' tempo a star dietro agli scc che non a scrivere codice.

[StM]

La "distribuzione" è una cosa che ci potrebbe servire molto, ci capita di portare avanti lo sviluppo anche fuori ufficio. Diciamo che sono confidente nella gestione dei merge, che è già un enorme passo avanti rispetto al "chi c***o è che mi ha sovrascritto il file per la terza volta?!?".

[Ziggybee]

Da quando ho cominciato a lavorare (5 anni fa) ho sempre cercato di introdurre le meraviglie di un qualsivoglia version control system collaborativo, ma quando è stato deciso di usare CVS (e io ero contento, meglio di niente) lo si è usato come mero contenitore di backup in cui ciascuno faceva le proprie commit separatamente (e allora sono stato molto meno contento). Con grande fatica sono riuscito a introdurre l'idea che non è vietato fare il checkout dal progetto di un altro, ma quanto alla commit è tutta un'altra storia.

Ora può essere che con l'anzianità mi diano un po' più retta (anche se paradossalmente sulle cose nuove si tende a dare più credito alle facce nuove e non a chi è lì da anni e ormai lo si crede fossilizzato in un ruolo specifico), e salvo contrordini cercherò di creare tutta una serie di pappe fatte per usare con successo Mercurial, anche se so già che in pochi si impegneranno per capirne il funzionamento e usarlo propriamente. Piuttosto si perdono le giornate dietro a problemi triviali, ma guai cambiare il metodo di lavoro.

Voi che esperienze avete avuto in proposito (che potete raccontare)?

Io ho sempre usato SVN, che è molto flessibile se configurato bene. Tranne che per i file binari, come dice Id.

Ultimamente sto utilizzando il Team Server di Microsoft perché avevamo bisogno di tutta una serie di tool per il monitoraggio e controllo remoto dei task durante lo sviluppo agile, assessment della qualità del codice e un profiler cazzuto, nonché di esporre documentazioni e milestone a gente che già è tanto se sa aprire il browser. Funziona abbastanza bene con qualsiasi linguaggio, il problema più grande è che il loro source control blocca i file che sono in edit da qualcuno...

Entrambi usati anche da remoto su HTTP

[Id]

Da quando ho cominciato a lavorare (5 anni fa) ho sempre cercato di introdurre le meraviglie di un qualsivoglia version control system collaborativo, ma quando è stato deciso di usare CVS (e io ero contento, meglio di niente) lo si è usato come mero contenitore di backup in cui ciascuno faceva le proprie commit separatamente (e allora sono stato molto meno contento). Con grande fatica sono riuscito a introdurre l'idea che non è vietato fare il checkout dal progetto di un altro, ma quanto alla commit è tutta un'altra storia.

Ora può essere che con l'anzianità mi diano un po' più retta (anche se paradossalmente sulle cose nuove si tende a dare più credito alle facce nuove e non a chi è lì da anni e ormai lo si crede fossilizzato in un ruolo specifico), e salvo contrordini cercherò di creare tutta una serie di pappe fatte per usare con successo Mercurial, anche se so già che in pochi si impegneranno per capirne il funzionamento e usarlo propriamente. Piuttosto si perdono le giornate dietro a problemi triviali, ma guai cambiare il metodo di lavoro.

Voi che esperienze avete avuto in proposito (che potete raccontare)?

Io ho sempre usato SVN, che è molto flessibile se configurato bene. Tranne che per i file binari, come dice Id.

Finche' non ti ritrovi alle prese con un svn merge o un svn diff da riga di comando, almeno.

[Ziggybee]

TortoiseSVN e ti salvi la vita!

[Id]

TortoiseSVN e ti salvi la vita!

Eh, gia', peccato che la versione Mac sia un tantino non-esistente. E se devi sviluppare per iPhone, il mac ti tocca per forza.

[Ziggybee]

Hai varie scelte.

C'è l'SCM di Xcode che funziona anche da front-end SVN.

C'è SCPlugin, che però non ricordo se faccia i merge.

[Id]

Hai varie scelte.

C'è l'SCM di Xcode che funziona anche da front-end SVN.

C'è SCPlugin, che però non ricordo se faccia i merge.

Nessuno dei due fa i merge.
Che e' la ragione per cui uso svn checkout per tirar giu' il progetto "ultima revisione" in una cartella a parte e poi KDiff per i merge.

[Ziggybee]

Hai sempre filemerge nell'SDK di Apple, vecchio mio!

Sempre meglio della riga di comando!

[Ziggybee]

Ma quante volte ti capita?

Se dovete mergiare (gh!) molto spesso avete assolutamente bisogno di un ingegnere del software bravo che sappia le sue cosette... (non di uno laureato in ma di uno che per lavoro l'ha fatto!)

[Id]

Ma quante volte ti capita?

Se dovete mergiare (gh!) molto spesso avete assolutamente bisogno di un ingegnere del software bravo che sappia le sue cosette... (non di uno laureato in ma di uno che per lavoro l'ha fatto!)

"Quante volte ti capita?" e' una domanda mal posta. La domanda giusta per un'analisi di costi-benefici e' "quanto tempo ci perdi?", e la risposta e': io, non molto.
Nel codice su cui lavoro non capita quasi mai di dover fare merge, e se capita ci pensa l'automerge. Alla fine della fiera, i conflitti sono rari.

Poi, non e' che vada sempre cosi'.

Piu' gente c'e' su un progetto, piu' spesso e' necessario un merge tra i propri file in locale e quelli sul repository. Oltre un certo numero di persone, diventa una necessita' quotidiana, ingegneri del sw o meno. In ogni caso, dipende da come si lavora: ho visto gente usare la meccanica del branch/merge su scm centralizzati per simulare scm distribuiti. NON e' una buona idea, ma l'ho visto fare. Altre volte, si brancha un progetto per farne un port, e mentre X persone lavorano al port, ce ne sono altre Y che modificano il progetto originale - a queste X persone, in qualche grado, il merge delle novita' fatte dalle altre Y persone tocca per forza (e a volte pure viceversa). Dipende.

Morale: qualsiasi tool di scm che non sia SourceSafe il versioning lo fa in maniera dignitosa. Dopo quello, la mia valutazione la faccio sui tool di branch e di merge. 

[Monopoli]

a me piace perforce Funziona bene e ci puoi fare tanti script facilmente in tutti i linguaggi

[Ziggybee]

Il fatto che sui progetti grandi è naturale che ci siano molti merge è una leggenda/giustificazione. Ma è un discorso molto esteso e specialistico.

Te lo dico per esperienza su progetti-tipo da 30 persone, 20 M€ in campo aerospaziale/ricerca/robotica/sicurezza (firmware), per non dire molto. Anche con 5 persone, per mia esperienza, è critico mantenere le collisioni e le sovrapposizioni al minimo. Se devi battere un chiodo non servono due martelli.

Gli SCM distribuiti sono una cosa che io non riesco a capire. Sono il contrario di quello per cui servirebbe un SCM, hanno un sacco di parti mobili e tutti sappiamo che in qualsiasi cosa più parti mobili ci sono, più è facile rompere qualcosa. In questi casi la semplciità è molto migliore e più affidabile della complessità.

[StM]

a me piace perforce Funziona bene e ci puoi fare tanti script facilmente in tutti i linguaggi

Cioè puoi automatizzare operazioni usando il linguaggio che preferisci?

(non l'ho preso in considerazione perché è a pagamento, e visto che si rischia di non usarlo granché...)