ArsLudica.org Forum
Cogitare => Officina Creandi => Topic aperto da: StM - Gennaio 25, 2011, 16:39:33
-
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)?
-
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 :bua: )
- 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.
-
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?!?".
-
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
-
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. :bua:
-
TortoiseSVN e ti salvi la vita!
-
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.
-
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.
-
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.
-
Hai sempre filemerge nell'SDK di Apple, vecchio mio!
Sempre meglio della riga di comando!
-
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!)
-
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.
-
a me piace perforce :D Funziona bene e ci puoi fare tanti script facilmente in tutti i linguaggi :)
-
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à.
-
a me piace perforce :D Funziona bene e ci puoi fare tanti script facilmente in tutti i linguaggi :)
Cioè puoi automatizzare operazioni usando il linguaggio che preferisci? :o
(non l'ho preso in considerazione perché è a pagamento, e visto che si rischia di non usarlo granché...)
-
a me piace perforce :D Funziona bene e ci puoi fare tanti script facilmente in tutti i linguaggi :)
Perforce in realtà è un gestore della configurazione, fa molto più di semplice source control! L'ho usato in una delle tante riscritture del sistema di videostreaming di RAI TV :P
-
Il problema, Matteo, è se vale la pena.
Se lo staff non sa usarlo poi te lo incasina, se non è pratico di SCM le prime settimane passerai il tempo a far undo su branch sbagliati o a far capire ai coglionazzi che devono fare update tutti e le mattine per allineare all'ultima buld che ha passato gli unti test e via discorrendo...
Usare strumenti troppo complessi, tipo Maven, Perforce, VSS/Team Server, può essere ancora più improduttivo e difficile.
-
a me piace perforce :D Funziona bene e ci puoi fare tanti script facilmente in tutti i linguaggi :)
Cioè puoi automatizzare operazioni usando il linguaggio che preferisci? :o
(non l'ho preso in considerazione perché è a pagamento, e visto che si rischia di non usarlo granché...)
Si, puoi farci gli script con quello che ti pare :) Beh, quasi:
http://www.perforce.com/perforce/loadsupp.html (http://www.perforce.com/perforce/loadsupp.html)
Non sono tutti, ma sono abbastanza :)
Io l'ho usato in python e puoi fargli fare quello che vuoi. Alla fine P4V, il suo client, e' proprio quello: un client che chiama con la sua API il tool a riga di comando.
-
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à.
Guarda, nel campo in cui lavoro io (sanità) puoi sbatterti quanto vuoi per fare software personalizzabile in ogni suo aspetto eppure col codice alla base solido, ma basta che cambi provincia e sembra di essere in un'altra nazione (non per nulla l'Italia è l'unico posto al mondo in cui una multinazionale non riesce a piazzare una certa parte di una sua soluzione completa e quindi gliela facciamo noi :P). Alcune versioni dei nostri prodotti viaggiano in parallelo per molto tempo perché devi mediare tra il prodotto che hai venduto e quello che i clienti si accorgono improvvisamente di volere (e finché non li soddisfi non firmano il collaudo), magari in più siti contemporaneamente. Non è un problema di analisi preventiva (anche perché vendiamo prodotti consolidati), è proprio un problema di testadicazzismo :asd:.
Negli esempi di progetto che citi tu (che non hanno molto da interagire con gli utenti?) invece mi sembra naturale pretendere una solidità molto maggiore.
-
Il problema, Matteo, è se vale la pena.
Se lo staff non sa usarlo poi te lo incasina, se non è pratico di SCM le prime settimane passerai il tempo a far undo su branch sbagliati o a far capire ai coglionazzi che devono fare update tutti e le mattine per allineare all'ultima buld che ha passato gli unti test e via discorrendo...
Usare strumenti troppo complessi, tipo Maven, Perforce, VSS/Team Server, può essere ancora più improduttivo e difficile.
Per me varrebbe la pena provarci. Abbiamo un potenziale molto grande e prospettive di ulteriore crescita, dobbiamo
*tenere traccia di ogni versione rilasciata ed evitare di dover fare un bugfix per ciascuna separatamente
*evitare il caos derivato dall'allargamento del team
*liberarci del vincolo che ogni parte del codice, anche le più triviali, sono gestite da un unico sviluppatore e se qualcun altro deve metterci le mani ci vuole un'ora per passarsi tutto, oppure bisogna aspettare che il titolare abbia del tempo libero/sia in ufficio
Poi personalmente avrei imparato molte meno cose se si fosse usato fin da subito un sistema di controllo delle revisioni (non mi sarei sbattuto a inventarmi buildfile di ant sempre più divertenti), ma visto che ormai le ho imparate sarei contento se cominciassimo ad usarlo ora :asd:
-
Gli SCM distribuiti sono una cosa che io non riesco a capire. Sono il contrario di quello per cui servirebbe un SCM [cut]
In realta' non sono "il contrario". Sono "il doppio", ed e' proprio questo passaggio in piu' che mi sta sul culo.
Normalmente, quando lavoro con un scm "normale", tiro giu' tutti i giorni l'ultima versione del codice per mantenermi aggiornato. Conservo in locale le mie modifiche fino a che non ho completato il mio task, e poi lo mando al server. Questo evita che io committi dei file "incompleti" che non compilano o non vengono eseguiti correttamente, e che di conseguenza le mie modifiche impattino sul lavoro del team; il prezzo da pagare e' che di questi file, tra la versione che ho preso dal server e quella che mandero' sul server, non ho history.
Questo e' il problema che affronta un scm distribuito.
Da una parte c'e' il repository "centrale"; dall'altra ne ho uno mio "locale" . Ogni volta che arrivo ad un punto che mi interessa conservare del mio codice (che ne so, il codice funziona pero' se ravano un'altra roba funziona meglio - ma non sono sicuro che se ravano quella roba poi non vada tutto a rane), posso fare un commit locale senza intaccare il lavoro degli altri (che pescano dal loro repository locale). Quando il mio task e' pronto, ed e' ora di condividerlo con gli altri, committo il mio repository "locale" su quello "centrale". Male che vada posso sempre fare un revert "locale" e via. Di tutto questo, il resto del team non sa nulla.
Quello che non mi piace e' che poi si passa da dire "aggiornami il progetto in locale" a "aggiornami il repository locale da quello principale, poi la working copy da quello locale, poi...." e alla fine non resta piu' tempo per scrivere codice ._.
-
Infatti, Id! Per noi sarebbe impossibile.
Ormai siamo agili al 100% (facciamo al 90% che ci sono sempre quelle 2-3 persone che fanno di tutto per non seguire i workflow di progetto) e facciamo anche tre working build al giorno, con relativi unit test, più una sessione di testing "interattivo".
Se ci mettessimo anche a fare ottomila sincronizzazioni della minchia il casino sarebbe esponenziale e sarebbe difficile anche decidere come continuare con le attività dei task successivi, pensa te a farle!
Poi considera che in uno degli ultimi progetti dobbiamo far coesistere, Python, ASP.NET/Silverlight, C#, C++ e Objective C, ci mancherebbero solo i repositori distribuiti!
L'unico casino grosso che ho avuto è stato gestire la messa in campo di un grappolo di cluster composto da 87 server, tutti attivi.
Ma è una cosa che ti capita di fare una o due volte nella vita... Spero.
-
Infatti, Id! Per noi sarebbe impossibile.
[cut]
Se ci mettessimo anche a fare ottomila sincronizzazioni della minchia il casino sarebbe esponenziale e sarebbe difficile anche decidere come continuare con le attività dei task successivi, pensa te a farle!
Per quello dico che nonostante ne comprenda la teoria e il senso, non mi piacciono: l'idea e' buona, ma la pratica rimane discutibile.
Anche perche' se un qualcosa di storto finisce sul repository "centrale" (la teoria e' che non dovrebbe succedere, la pratica e' che scm distribuito o meno succede eccome), poi si propaga a tutti gli altri e in breve tempo scatta il panico a catena, e in piu' va ri-propagato il fix a tutti i repository locali :bua:
E poi, se due task di due persone sono in conflitto, ti lascio immaginare cosa succede :bua:
-
Aggiungo questo link che e' pertinente:
http://www.gamasutra.com/view/feature/5900/branching_for_the_win_how_black_.php (http://www.gamasutra.com/view/feature/5900/branching_for_the_win_how_black_.php)
-
Vedo che un punto interessante di Perforce è il mapping lato client, mentre per quel che ne so negli altri sistemi ti becchi i file nella stessa posizione in cui sono nel repository (e tra l'altro ci sono dei repository di progetti open source in cui la gente piazza i file di configurazione specifici dei suoi IDE, magari anche col path delle sue risorse locali... che macello ^^). E' una cosa solo di Perforce?
-
Vedo che un punto interessante di Perforce è il mapping lato client, mentre per quel che ne so negli altri sistemi ti becchi i file nella stessa posizione in cui sono nel repository (e tra l'altro ci sono dei repository di progetti open source in cui la gente piazza i file di configurazione specifici dei suoi IDE, magari anche col path delle sue risorse locali... che macello ^^). E' una cosa solo di Perforce?
E' una feature "base" di qsiasi sistema di version control, da quanto ne so.
Poi, in certi vcs e' "fissa" (svn, ad esempio, ha il comando "checkout" che stabilisce la mappatura fra struttura del repository e file system locale, e una volta che hai fatto checkout la cartella e' quella li' e non ci sono santi), in altri (Perforce e Alienbrain, tra gli altri) e' possibile cambiarla a piacere.
E, naturalmente, in certi vcs funziona meglio, in altri mica troppo (svn ogni tanto fa bordello - se hai una cartella locale "A" mappata su "repository/A" e una cartella locale "A/B" che invece e' legata a "repository/B", se chiedi un commit o un update di "A/B" e come working directory hai "A/B", la risolve correttamente; se la tua working directory e' "A" invece si aspetta che ci sia una cartella "repository/A/B", per ragioni imperscrutabili).
-
La faccenda del mapping forse la risolvo con una struttura fissa e link simbolici lato client. Eee vabbe'.
La cosa che mi sta lasciando interdetto invece è che mercurial richiede un "hg add" esplicito per ogni singolo file che decidiamo di aggiungere al controllo di revisione. Cioè se non te lo ricordi tu non ti viene segnalato che ci sono nuovi file nemmeno nella commit. TortoiseHG e il plugin di eclipse poi non aiutano perché non si sbattono a cercare ricorsivamente tutti i file non sotto controllo (oppure non funzionano)...
E' un po' una seccatura.
-
il tool di eclipse te li segnala quelli che non sono versionati, con un bel punto interrogativo sull'icona. Poi quando fai Team->Commit, compaiono nella lista e puoi decidere cosa committare o meno.
-
il tool di eclipse te li segnala quelli che non sono versionati, con un bel punto interrogativo sull'icona. Poi quando fai Team->Commit, compaiono nella lista e puoi decidere cosa committare o meno.
Questo con cvs e svn, ma non con il plugin per mercurial :(
-
La faccenda del mapping forse la risolvo con una struttura fissa e link simbolici lato client. Eee vabbe'.
La cosa che mi sta lasciando interdetto invece è che mercurial richiede un "hg add" esplicito per ogni singolo file che decidiamo di aggiungere al controllo di revisione. Cioè se non te lo ricordi tu non ti viene segnalato che ci sono nuovi file nemmeno nella commit. TortoiseHG e il plugin di eclipse poi non aiutano perché non si sbattono a cercare ricorsivamente tutti i file non sotto controllo (oppure non funzionano)...
E' un po' una seccatura.
Invece e' normale, e' cosi' un po' per tutti i sistemi di vcs: almeno, anche per perforce, svn e Alienbrain e' cosi'. E secondo me e' giusto - certe volte non vuoi versionare un file, anche se e' nell'albero delle directory sotto vcs. Ad esempio, ultimamente, ho avuto bisogno di rifare un file di codice sorgente intero, per cui ne ho fatta una copia locale (guardare history e diff e' scomodo da riga di comando, ma si fa con quel che c'e' ) che NON voglio versionare, perche' era gia' versionata comunque, e con il nome corretto. Piuttosto che doverlo rimuovere ad ogni commit, preferisco aggiungere io a mano i file nuovi man mano che li creo.
Tant'e' che l' "add automatico" dei plugin del Visual Studio e di altri IDE, ad esempio, in realta' non e' gestito dal sistema di vcs, ma dal Visual Studio stesso tramite i file .vss[qcosa, non mi ricordo], che tiene traccia "questo e' versionato, questo no, questo va aggiunto" ._.
-
Io ho sempre usato semplicemente .cvsignore, e potrei usare .hgignore, per i file e le cartelle che non voglio gestire (infatti ho intere sottocartelle che ho escluso dal monitoraggio). La cosa migliore sarebbe che lo chiedesse almeno una volta, come mi succede con cvs e svn (anche usando i tortoise* relativi).
-
Più che altro è un'assunzione sbagliata che se un file è sotto un albero, allora è da aggiungere al repository.
-
Più che altro è un'assunzione sbagliata che se un file è sotto un albero, allora è da aggiungere al repository.
Per java è abbastanza logico che tutti i file che stanno nella cartella dei sorgenti finiscano nel repository (se non sono sorgenti correlati vuol dire che li metto in un altro progetto), e come ben sappiamo in java capita continuamente di aggiungere nuovi file. Ammetto che per altri linguaggi possano esserci molti motivi per non infilare nel repository qualsiasi cosa.
Comunque ho "risolto", per ora, facendo la ricerca di tutti i file da windows e facendo fare un hg add per tutti a TortoiseHG. La stranezza è che da questo sono stati esclusi i file .old, non so per colpa di chi (io non li ho messi in .hgignore).
Poi oggi mi sono rallegrato che per fare "la" commit iniziale di un progetto con qualche decina di migliaia di file in realtà ho dovuto fare una ventina di commit, per via del limite di lunghezza della linea di comando. Immagino sia il plugin ad essere ancora AMPIAMENTE migliorabile.
-
Più che altro è un'assunzione sbagliata che se un file è sotto un albero, allora è da aggiungere al repository.
Per java è abbastanza logico che tutti i file che stanno nella cartella dei sorgenti finiscano nel repository (se non sono sorgenti correlati vuol dire che li metto in un altro progetto), e come ben sappiamo in java capita continuamente di aggiungere nuovi file. Ammetto che per altri linguaggi possano esserci molti motivi per non infilare nel repository qualsiasi cosa.
La penso come Cherno, e anch'io non trovo l'assunzione "tutti i file che stanno nella cartella dei sorgenti dovrebbero stare nel repository" COSI' ovvia, ad onor del vero.
E' ovvio - e lo e' in qsiasi linguaggio - solo se sei ordinato, e quindi non come me, che tutte le volte che faccio "svn status" mi vien fuori una lista immonda di cose che non sono uguali al server o che non ci sono proprio, e va bene che sia cosi'. E' che sono "file correlati" ma magari mi servono un giorno si' e due no per test o debug, o e' un backup "di riferimento" di qcosa che sto rifattorizzando e voglio tenere una copia della versione originale, o un mio livello di test "usa e getta" che sono un cialtrone e non c'ho voglia di cancellare perche' "sai mai", o... :asd:
-
Io le cose di test le metto in progetti appositi in cui faccio tutte le porcherie che voglio, mentre le cose diverse tra client e server possono essere i file di configurazione (che bisogna tracciare in qualche modo se vengono aggiunti parametri, ma senza perdersi le personalizzazioni... argh!). E la rifattorizzazione sarebbe proprio il punto in cui il versioning (con branching efficente) serve, senza bisogno di tenere una copia di un sorgente :teach:
Comunque voglio specificare che non sto cercando di fare il saputello con Id, alla cui sapienza m'inchino e sempre m'inchinerò :asd:.
Probabilmente io ho passato quasi più tempo a studiare gli strumenti per programmare e a creare librerie e utilities (infatti sono il consulente fisso quando qualcosa non funziona :asd:) che a programmare veramente o creare cose frontend, perciò bado molto alla forma dei "processi produttivi".
-
Io le cose di test le metto in progetti appositi in cui faccio tutte le porcherie che voglio, mentre le cose diverse tra client e server possono essere i file di configurazione (che bisogna tracciare in qualche modo se vengono aggiunti parametri, ma senza perdersi le personalizzazioni... argh!). E la rifattorizzazione sarebbe proprio il punto in cui il versioning (con branching efficente) serve, senza bisogno di tenere una copia di un sorgente :teach:
Comunque voglio specificare che non sto cercando di fare il saputello con Id, alla cui sapienza m'inchino e sempre m'inchinerò :asd:.
Probabilmente io ho passato quasi più tempo a studiare gli strumenti per programmare e a creare librerie e utilities (infatti sono il consulente fisso quando qualcosa non funziona :asd:) che a programmare veramente o creare cose frontend, perciò bado molto alla forma dei "processi produttivi".
Massi', dai, siam qui a parlare. Confrontare opinioni ed esperienze diverse e' l'intero senso della questione, nessuno pensa di darti del saputello :asd:
Per il resto, hai ragione: il refactoring e il porting sono le due cose per le quali generalmente versioning e branching efficienti sono capitali.
Poi dipende: se devo fare refactoring di una parte molto piccola - una giornata o due, non di piu', non sto a fare un branch apposta di tutto quanto il progetto, faccio prima a tenermi una copia del file in locale e bon.
E' che poi sono disordinato e non la cancello, che e' un mio difetto ma ho imparato a conviverci e quindi tipicamente me ne fotto e quel file rimane li' :bua:
Un'altra buona ragione e' che IMO il branching di SVN fa cagare e dove lavoro usiamo quello :bua:
Le cose di test mi piacerebbe farle, solo che sono sempre in produzione e non ho il tempo. "Fare o non fare, non c'e' provare" :bua:
-
Io le cose di test le metto in progetti appositi in cui faccio tutte le porcherie che voglio, mentre le cose diverse tra client e server possono essere i file di configurazione (che bisogna tracciare in qualche modo se vengono aggiunti parametri, ma senza perdersi le personalizzazioni... argh!). E la rifattorizzazione sarebbe proprio il punto in cui il versioning (con branching efficente) serve, senza bisogno di tenere una copia di un sorgente :teach:
Comunque voglio specificare che non sto cercando di fare il saputello con Id, alla cui sapienza m'inchino e sempre m'inchinerò :asd:.
Probabilmente io ho passato quasi più tempo a studiare gli strumenti per programmare e a creare librerie e utilities (infatti sono il consulente fisso quando qualcosa non funziona :asd:) che a programmare veramente o creare cose frontend, perciò bado molto alla forma dei "processi produttivi".
Ma no, non è il fatto di fare i saputelli però giustamente come dice Id dipende dalla situazione in cui ti trovi. Quindi preferisco che l'automatismo, nel caso specifico, non ci sia, perchè a volte è deleterio
-
Devo aver detto una fesseria. Mercurial di default ti chiede se vuoi aggiungere i file nuovi creati, mi ero infognato con una regular expression :bua:. Ma continuo a non capire perché mi ignori gli .old e .bak senza possibilità di appello :(
-
Devo aver detto una fesseria. Mercurial di default ti chiede se vuoi aggiungere i file nuovi creati, mi ero infognato con una regular expression :bua:. Ma continuo a non capire perché mi ignori gli .old e .bak senza possibilità di appello :(
Te lo chiede Mercurial, o il plugin per Eclipse? Cosi' per curiosita'.
Per gli .old e i .bak, che ti devo dire, sono vcs, son fatti cosi'. SVN a me ignora con regolarita' i file .a, dev'essere che ogni vcs c'ha un po' le sue antipatie :bua:
-
Sia il plugin per Eclipse che TortoiseHG, e mi sa che "hg add" aggiunge automaticamente tutti i file non in .hgignore (adesso non ho il computer con il repository acceso, domani controllo). Poi da linea di comando si possono specificare varie opzioni, ad esempio ad "hg commit", quindi direi che c'è flessibilità.
A parte qualcosina qua e là, oltre a qualche baco nel plugin, l'unico grosso dubbio che mi rimane è il fattore umano :asd:
-
Sia il plugin per Eclipse che TortoiseHG, e mi sa che "hg add" aggiunge automaticamente tutti i file non in .hgignore (adesso non ho il computer con il repository acceso, domani controllo). Poi da linea di comando si possono specificare varie opzioni, ad esempio ad "hg commit", quindi direi che c'è flessibilità.
A parte qualcosina qua e là, oltre a qualche baco nel plugin, l'unico grosso dubbio che mi rimane è il fattore umano :asd:
Il fattore umano... io l'ho risolto definitivamente minacciando i miei colleghi di "graffetta piegata sotto le unghie". Funziona abbastanza.
-
E' bello che il casinista che si è appena costituito sia quello che detta legge per tenere sotto controllo il fattore umano!
Cmq StM, questa dichiarazione è agghiacciante: "A parte qualcosina qua e là, oltre a qualche baco nel plugin, l'unico grosso dubbio che mi rimane è il fattore umano".
-
Cosa ti agghiaccia di più delle 3 proposizioni? :asd:
-
Mi perplime usare strumenti inaffidabili per un processo che deve essere affidabile.
Io sono in ingegnere all'antica: meno parti si muovono e più il meccanismo è difficile che si rompa.
-
E' bello che il casinista che si è appena costituito sia quello che detta legge per tenere sotto controllo il fattore umano!
Ci sono dei vantaggi nell'essere lead :asd:
Poi e' vero, io sono casinista in locale, lo ammetto serenamente - ma quando ho scritto "ho imparato a conviverci", intendo dire che so tenermi il disordine in locale mantenendo ordinato il repository del vcs, cosi' i miei colleghi non diventano scemi.
-
Mi perplime usare strumenti inaffidabili per un processo che deve essere affidabile.
Io sono in ingegnere all'antica: meno parti si muovono e più il meccanismo è difficile che si rompa.
Mal che vada, si spacca tutto insieme. Nè? :D
-
Mi perplime usare strumenti inaffidabili per un processo che deve essere affidabile.
Io sono in ingegnere all'antica: meno parti si muovono e più il meccanismo è difficile che si rompa.
I problemi che ho riscontrato sono solo delle noie, tipo il fatto che il plugin non gestisce commit di notevoli quantità di file contemporaneamente. Ma quanto all'affidabilità di mercurial non ho dubbi (probabilmente qualche volta si comporterà in modo inaspettato, visto che ha le sue abitudini strane, come ad esempio la copia di file tiene traccia del file di origine... ma non è un bug, è una feature :P).
Il problema del fattore umano invece è più che altro l'atteggiamento di non avere voglia di imparare ad usare le cose e 1) rifiutare di usarle o 2) usarle con scazzo e odio cercando di sputtanare tutto.
-
Mi perplime usare strumenti inaffidabili per un processo che deve essere affidabile.
Io sono in ingegnere all'antica: meno parti si muovono e più il meccanismo è difficile che si rompa.
I problemi che ho riscontrato sono solo delle noie, tipo il fatto che il plugin non gestisce commit di notevoli quantità di file contemporaneamente. Ma quanto all'affidabilità di mercurial non ho dubbi (probabilmente qualche volta si comporterà in modo inaspettato, visto che ha le sue abitudini strane, come ad esempio la copia di file tiene traccia del file di origine... ma non è un bug, è una feature :P).
Certo che e' una feature :|
Considera che se copi un file A creando un file B, di fatto hai branchato A, e ne tiene traccia per non perdere lo storico. Non e' del tutto stupido :|
Il problema del fattore umano invece è più che altro l'atteggiamento di non avere voglia di imparare ad usare le cose e 1) rifiutare di usarle o 2) usarle con scazzo e odio cercando di sputtanare tutto.
Insisto con la graffetta. Funziona. Vedrai che alla terza volta, hanno imparato tutti. :sisi:
-
Il problema del fattore umano invece è più che altro l'atteggiamento di non avere voglia di imparare ad usare le cose e 1) rifiutare di usarle o 2) usarle con scazzo e odio cercando di sputtanare tutto.
Non credi che costringere la gente ad imparare workaround o accorgimenti aggiuntivi non faccia che esacerbare ancora di più la loro naturale ostilità ad uno strumento che gli viene imposto? Oltre che a fornire strumenti per dimostrarti che avevano ragione, mettendo in pratica il punto 2.
La mia esperienza mi ha insegnato che già di per sé è difficile far capire ai programmatori che una disciplina serve anche per migliorare la loro vita lavorativa, oltre che la qualità e l'affidabilità dello sviluppo (mi viene in mente quando qualche anno fa introdussi il test driven development per alcuni componenti di progetto, ci fu un ammutinamento di due mesi prima che gli sviluppatori stessi inziassero a riconoscere che gli rendeva la vita più semplice rispetto ai loro metodi da trial & error), se ci metti pure degli strumenti o delle metodologie che sono percepite come il proverbiale Dito Al Culo (altrimenti detto DAC) perché non funzionano perfettamente o obbligano la gente già negativa a pensarci su per farle andare, non c'è vantaggio o visione che tenga.
Io stesso funziono così.
-
Ma quanto all'affidabilità di mercurial non ho dubbi (probabilmente qualche volta si comporterà in modo inaspettato, visto che ha le sue abitudini strane, come ad esempio la copia di file tiene traccia del file di origine... ma non è un bug, è una feature :P).
Certo che e' una feature :|
Considera che se copi un file A creando un file B, di fatto hai branchato A, e ne tiene traccia per non perdere lo storico. Non e' del tutto stupido :|
Infatti è molto interessante, però è uno dei modi in cui mercurial si stacca molto dal modo di pensare lineare di chi pensa in termini di filesystem.
Il problema del fattore umano invece è più che altro l'atteggiamento di non avere voglia di imparare ad usare le cose e 1) rifiutare di usarle o 2) usarle con scazzo e odio cercando di sputtanare tutto.
Non credi che costringere la gente ad imparare workaround o accorgimenti aggiuntivi non faccia che esacerbare ancora di più la loro naturale ostilità ad uno strumento che gli viene imposto? Oltre che a fornire strumenti per dimostrarti che avevano ragione, mettendo in pratica il punto 2.
La mia esperienza mi ha insegnato che già di per sé è difficile far capire ai programmatori che una disciplina serve anche per migliorare la loro vita lavorativa, oltre che la qualità e l'affidabilità dello sviluppo (mi viene in mente quando qualche anno fa introdussi il test driven development per alcuni componenti di progetto, ci fu un ammutinamento di due mesi prima che gli sviluppatori stessi inziassero a riconoscere che gli rendeva la vita più semplice rispetto ai loro metodi da trial & error), se ci metti pure degli strumenti o delle metodologie che sono percepite come il proverbiale Dito Al Culo (altrimenti detto DAC) perché non funzionano perfettamente o obbligano la gente già negativa a pensarci su per farle andare, non c'è vantaggio o visione che tenga.
Io stesso funziono così.
Innanzitutto non c'è imposizione. Io ho fatto una proposta, qualcuno si è detto d'accordo, finora nessuno ha detto "no, manco morto". Penso che anni di sfiancamento a causa dei problemi di un certo modo di fare sviluppo abbiano fatto nascere il desiderio di un miglioramento.
L'unica cosa che è un "workaround" è la, forse temporanea, mappatura generica del progetto con eventuale utilizzo di symlink (con eclipse non sono necessari); ma questo perché così nessuno è costretto a un particolare IDE, visto che ogni IDE ha i suoi bei punti deboli irrisolti da anni ed è inutile imporne uno a tutti se nessuno fa bene TUTTO.
Per il resto mi sembra che i vantaggi superino ampiamente gli svantaggi e il (poco) lavoro in più. Ma metto le mani avanti perché mi rendo conto che non tutti, avendo raggiunto un alto livello di produttività con i propri strumenti (per carità, più che sufficienti se si lavora da soli), ha voglia di abbassarla per una giornata intera per imparare qualcosa di nuovo con la *dovuta pazienza*.
Non vedo la divergenza tra "cose che vanno perfettamente" e "pensarci su per farle andare". Per un normale workflow mercurial è *facile*. Il branching e merge è appena appena più complicato. Per finezze particolari come modificare la release 14 e riportare il bugfix alle release successive magari c'è un po' da leggere, ma se l'alternativa è andare a scavare nei backup zippati una particolare versione del progetto, di cui hai solo i tuoi sorgenti e non quelli degli altri, compilare alla speraindio... be', direi che è grasso che cola.
(sto esagerando... ma non troppo :asd:)
-
Sembra funzionare piuttosto bene, l'amico Mercurial. Certo, la decentralizzazione aggiunge dei passaggi all'operazione di commit (che porta potenzialmente con sé un'operazione di merge ogni volta - operazione in genere automatica, comunque), ma spesso sviluppiamo sul campo e quindi è in realtà un valore aggiunto.
Magari è presto per cantare vittoria, ma la temuta negatività non è per ora pervenuta, sono stato pessimista :look:
-
Io sto avendo dei problemi di build management sul progetto del nostro nuovo prodotto... Piano tirennale, roba grossa.
Abbiamo circa 20 persone che sviluppano e non seguono alcuna logica umana.
I problemi sono anche di tipo organizzativo (non c'è alcuna pipeline di sviluppo: il mercato chiede e loro fanno). Nessuno è coordinato con niente. Se l'utente A implementa una feature, forka e la scrive. L'ultimo che finisce prima della release della milestone si becca il merge (mentre facevo l'auditing del vecchio processo uno è durato 4 ore e mezzo, la media è 1:10).
Siccome non c'è una persona una che ha una del totale del progetto (che non è concettualmente così complesso da non renderlo possibile è solo che in due anni di preliminari non hanno scritto un cazzo di documentazion e con il tempo l'analisi iniziale è diventata una leggenda urbana tramandata la sera dopo gli straordinari non pagati), chi fa il merge spesso non è che sa bene cosa sta facendo... Non vi dico cosa succede al testing (fatto a mano)...
Insomma morale della favola, stiamo cercando di riorganizzare tutto e si parte proprio dal source e dal build management. Al momento usiamo questa tecnica:
All'inzio di ogni sprint (al momento intese in senso molto lato) decidiamo le nuove feature e chi se ne occupa.
Ogni gruppo che si occupa di una feature brancha il proprio codice e a feature è conclusa fa il merge con il trunk di sviluppo. E' un merge di nome e non di fatto: il codice è separato, quindi i task sono verticalizzati in maniera tale che i vari gruppo di lavoro si occupano dello stesso subset di componenti, così ci sono collisioni minime. Il merge non lo fa un pincopallo a cazzo, lo fa un build manager (uno degli sviluppatori senior o io) che si fanno aiutare dal team leader del gruppo di lavoro. Questo non tanto per allineare versioni e dirimere collisioni quando per verificare che la qualità del codice sia garantita (usiamo i tool di visual studio ma non è sbagliato assicurarsi che i dev più giovani non stiano prendendo brutte pieghe).
A fine milestone, il trunk di sviluppo è tornato sano, si verifica che buildi e si passa tutto al trunk di release. Il build manager a quel punto dà luce verde a chi si occupa dei test che procedono da unit testing in su (sino a test automatizzati di VS, non tutto è testabile a quel modo ma è sempre meglio di far fare tutto a mano ad un pincopallo scazzato che deve scorrere un excel di casi di test), producendo un casino di report, tra cui uno stato di qualità del codice (molto utile quello di copertura del codice che ci fa capire se abbiamo impostato male i test o abbiamo codice morto).
A questo punto si riparte con un altro sprint, la cui prima attività (1 giorno circa) è decidere se bisogna modificare le frontiere (interfacce, web service, etc) dei vari sistemi per implementare le nuove feature. Se si, si procede alla modifica delle stesse e alla creazione di eventuali Stub per avere il codice buildabile, poi si parte con l'implementazione delle nuove cose. Ad ogni fine giornata, chiunque abbia lavorato deve committare tutto con merge automatico. Se non ci sono collisioni da sistemare a mano, di notte il server builda e il mattino sappiamo se ci sono problemi grossolani.
Devo dire che nonostante sembri tutto complicato funziona piuttosto bene (e abbiamo praticamente annullato i merge in senso stretto, anche se per arrivarci ho dovuto fare 2 sett e mezzo di refactoring praticamente da solo, perché quasi nessuno aveva idea di dove si potesse arrivare con un po' di disciplina).
Ora resta l'ultimo scoglio: passare il controllo ai quattro team da cinque per la definizione dei task negli sprint settimanali: si stanno letteralmente cagando sotto, anche se due settimane fa hanno dovuto subire la sottostima di un'attività (di solo il 637%, che volete che sia) fatta da terzi. Visto che la qualità del lavoro era bassa e i cazziatoni costanti, sono convinti che prendersi direttamente la responsabilità sul decidere cosa fare e per quando farlo sia errata. Al momento partiremo con i team leader che stimano le attività ma l'idea finale è che ogni sviluppatore diventi padrone della sua velocity e la usi al meglio, anche in funzione di impegni personali, etc etc...
-
La mancanza di una "pipeline di sviluppo" è un nostro problema a cui stiamo cercando di mettere qualche pezza, ma nel nostro settore è impossibile pensare di non soddisfare immantinente il cliente mettendoci anche a 90, quindi alcune cose vengono fatte fast&furious. Tra gare di appalto, ricatti più o meno velati, direttori-dittatori che tengono i cordoni della borsa, project manager che devono far firmare il collaudo il prima possibile, non c'è proprio verso di dire "aspettate la prossima release" :P.
Oggi su mercurial ho sperimentato la rimozione di una revisione sbagliata ormai impilata sotto varie revisioni giuste (ovvero il backout... ha funzionato!) e il merge di un branch di sviluppo con il branch principale per tenerlo allineato con le ultime modifiche pur mantenendoli separati (e ha funzionato pure questo! Magggico!). Per quanto ci impegnamo pare difficile fare casini senza via d'uscita... ma prima o poi ci riusciremo :proud:. Oltretutto mi pare che non sia così difficile da usare nemmeno per sviluppatori junior (o almeno, mi sembra che si pongano domande e si diano risposte sensate).
-
Considera che comunque MINIMO c'è un rilascio a settimana, quindi pure noi non è che siamo molto larghi con i tempi.
Il vantaggio è che se ti organizzi, tranne cause di forza maggiore a cui ti devi chinare, l'entropia che ti genera l'imprevisto a cui non puoi dire di no è molto ma molto minore... Il vantaggio è che alla fine tutti sono informati sullo stato, se non lo sono possono farsene un'idea chiedendo o visualizzando la dashboard del progetto. Sono sempre più convinto che più che fare le cose, in informatica, è opportuno mantenere ottime comunicazioni. Già con 4-5 persone è facile che la mano destra non sappia cosa faccia la sinistra, per non parlare che se poi ti capita un dev paraculo che insabbia le rogne è la fine!
-
Una cose che detesto è ricavare indirettamente l'informazione che un collega sta facendo qualcosa che, se chiedeva a me, risolveva in 10 minuti e senza far casini. Magari lo scopri quando ti fanno domande misteriose e indirette, in buona fede per carità, ma tante volte m'è venuto da chiedere: "scusa, ho seguito questa cosa per 3 anni qui dentro, perché non mi hai detto nulla che dovevi usarla/farci degli aggiornamenti/altro?"; oppure, "perché hai reinventato la ruota invece di chiedermi il codice collaudato che la faceva e al massimo adattarlo alle nuove esigenze?". E parlo di quelli che per certo SANNO che possono chiedere a me, poi ci sono quelli che non lo sanno e allora è un altro problema*.
*=anche questo non indifferente perché già solo il gruppo di sviluppatori si sta avvicinando alla trentina di componenti; per fortuna non più di 5-6 lavorano allo stesso progetto, ma il lavoro di alcuni impatta sul lavoro di 10-15 altri (e spesso lo tiene parzialmente fermo, ma dopotutto sono persone quasi insostituibili)... non ci stiamo muovendo male, ma molte cose abbiamo dovuto e le stiamo riorganizzando.
-
Un altro mese è passato, e a parte un caso di perdita del lavoro di 2 giorni di una persona (che ha forzato un update senza aver mai dato commit :sigh: - è un genio, ma a volte è un po' troppo "fai da te" quanto alle soluzioni per i problemi sconosciuti :P), per il resto ce la stiamo cavando bene. Il merge di due rami che sono proseguiti paralleli per un mesetto ci ha preso 15 minuti per via di 3 file che erano stati modificati indipendentemente, ma il resto è filato liscio in automatico.
A quota 100 revisioni le dimensioni di uno dei repository non è aumentato visibilmente (tra una revisione e l'altra ci sono prevalentemente differenze testuali).
In definitiva se il fatto che sia distribuito è uno dei vostri requisiti direi che mercurial è un'ottima scelta. Altrimenti probabilmente ci sono scelte migliori.