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.

[Ziggybee]

a me piace perforce 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

[Ziggybee]

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.

[Monopoli]

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é...)

Si, puoi farci gli script con quello che ti pare Beh, quasi:
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.

[StM]

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

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.

[StM]

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

[Id]

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

[Ziggybee]

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.

[Id]

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
E poi, se due task di due persone sono in conflitto, ti lascio immaginare cosa succede

[Id]

Aggiungo questo link che e' pertinente:
http://www.gamasutra.com/view/feature/5900/branching_for_the_win_how_black_.php

[StM]

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?

[Id]

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

[StM]

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.

[Cherno]

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.

[StM]

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

[Id]

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" ._.