Newsgroup: it.lavoro.informatica
Titolo: Svn complicato da usare in team, soluzioni?

Salve ragazzi è da qualche mese che stiamo cercando di usare l'svn in
azienda per aumentare la produttività e per una serie di altri motivi.
C'è un piccolo problema, il reparto di grafica non è in grado di usare
l'svn, o meglio sarebbe veramente troppo complicato spiegargli cosa
devono fare quando fanno le modifiche e prima di fare l'upload sul
server.
Avete esperienze in merito ad usare l'svn su un team misto? cioè con
persone che lo utilizzano e altre no?
In questo momento abbiamo un sacco di problematiche a gestirlo in
questa maniera perchè spesso mandiamo su delle modifiche e non ci
accorgiamo che magari i grafici avevano fatto dell'altro perchè sul
repository non c'è traccia del loro lavoro.
Qualcuno mi sa dare un consiglio.
Grazie mille

 Qualcuno mi sa dare un consiglio.
Io picchierei i grafici fino a inculcargli la nozione "controllo di
revisione". Non vedo altra soluzione...
-- 
Vide

 Qualcuno mi sa dare un consiglio.
Sostituire gli idioti dell'azienda con persone il cui QI sia superiore
a 40.
-- 
Salvatore Iovene
http://www.iovene.com

 Salvatore Iovenehttp://
www.iovene.com
Concordo pienamente, cvs e svn sono utilizzati tranquilalmente e con
successo non solo da programmatori ma anche da designer e 'artisti".
Dedicate un po' di tempo per spiegare loro bene bene come va
utilizzato e saranno loro i primi a ringraziarvi in seguito.

 server.
ma scusa non sanno usare questo?
http://tortoisesvn.tigris.org/
-- 
http://bpcsoluzioni.com/blog/

 Qualcuno mi sa dare un consiglio.
Come ha suggerito il nostro amico Vide, botte da orbi fino a che non
hanno imparato.

 utilizzato e saranno loro i primi a ringraziarvi in seguito.
E poi SVN e CVS hanno tonnellate di GUI appiccicabili sopra. Non c'è
bisogno di far usare loro la linea di comando...
-- 
Lawrence, 
oluyede.org
 - 
neropercaso.it
"It is difficult to get a man to understand 
something when his salary depends on not
understanding it" - Upton Sinclair

 utilizzato e saranno loro i primi a ringraziarvi in seguito.
Io abitualmente uso sia CVS sia SVN in riga di comando, quindi non ho
nessun problema. Ma mi associo al coro di persone che hanno consigliato
TortoiseSVN (o TortoiseCVS se si usa CVS), talmente intuitivo da
essere davvero a prova di imbecille: chi non lo riesce ad usare dovrebbe
davvero guardarsi allo specchio e domandarsi se non sia saggio darsi
all'ippica :-)
Tra l'altro, TortoiseSVN gestisce anche i path più lunghi di una certa
soglia (credo 255 caratteri), che sotto Windows con il client in riga 
di comando in una shell possono causare dei problemi.
TheStar
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 server.
Risolvi con l'organizzazione del lavoro.
Per ogni progetto in corso voi tecnici (che sapete usare svn) eleggete 
un project manager/coordinator che riceverà mail quotidiane sulle 
modifiche fatte dai grafici coinvolti nel progetto.
Il project manager provvederà a fare update sul repository tenendo conto 
di tutte le parti coinvolte nello sviluppo dell'applicazione (e per gli 
oggetti grafici all'inizio lo farà insieme ai creativi in modo che 
questi possano imparare piano piano ad usare un client GUI di svn).
Col tempo quando tutti avranno imparato ad usarlo il suo compito di 
"accentratore di update" diverrà superfluo.
P.S. ovviamente il boss deve essere d'accordo ed avallare col suo potere 
questa modifica di gestione del lavoro (in modo che i grafici se non 
mandano mail sulle modifiche fatte possano essere bastonati adeguatamente).
Bye
Jarod

 persone che lo utilizzano e altre no?
non è certo questa la strada.
a voi serve che il responsabile del progetto dica "si fa così e basta". 
e naturamente abbia il dovuto appoggio da chi paga gli stipendi.
e se vogliamo l'uso o meno di svn è secondario. il vostro problema è che 
a prescindere dagli strumenti usati i rilasci non si fanno così. non è 
accettabile che uno sviluppatore (grafico o no) modifichi il suo singolo 
orticello e lo schiaffi in produzione sbattendosene degli orticelli 
degli altri.
ma se questa sensibilità non c'è a livello di responsabilità di 
progetto, non vedo perchè la debba avere il grafico. chi lavora è come 
l'acqua, se nessuno la incanala passa sempre per i percorsi dove trova 
meno resistenza, ma ovviamente non irriga i campi.

 utilizzato e saranno loro i primi a ringraziarvi in seguito.
ribadisco il concetto: finchè gli è consentito di rilasciare le loro 
modifiche direttamente e a prescindere dagli altri componenti del team 
loro continueranno imperterriti a fare così, spiegare quanto è bello e 
ganzo svn è una perdita ti tempo perchè loro non ne vedranno mai e poi 
mai l'utilità.
sull'organizzazione del progetto o c'è sensibilità fra i responsabili 
altrimenti non puoi aspettarti che la gente si organizzi da sola.

 a voi serve che il responsabile del progetto dica "si fa così e basta".
...sottolineando il concetto facendosi vedere giocherellando con una
mazza da baseball.
P

 azienda per aumentare la produttività e per una serie di altri motivi.
Innanzi tutto credo che sia giustificabile che un grafico non conosca svn. 
Sarebbe piu' grave se fosse un programmatore. Poi, potrebbe essere che abbia 
utilizzato altri sistemi di versioning, ma non svn in particolare.
Comunque, ci sono 2 modi di affrontare il problema:
1) Con un mini-corso interno 2-3 ore, spieghi al reparto di grafica come si 
utilizza svn e i benefici derivanti dall'uso di questo sistema. Anche le 
persone che gia' usano svn dovrebbero seguire il corso, in modo da istruire 
il personale a seguire gli stessi standard e a utilizzare gli strumenti di 
lavoro secondo una unica prassi aziendale. Alla fine del corso in genere il 
personale e' soddisfatto, ha acquisito ulteriori conoscenze e ne comprende 
la loro utilita' nel lavoro quotidiano.
2) Il secondo approccio e' quello da team manager "all'italiana", come 
esemplificato da qualche messaggio nel thread. Ti incazzi di brutto e con il 
viso paonazzo vai dai grafici a dire loro che sono degli idioti con un 
quoziente < 40, che meriterebbero botte da orbi e che se non iniziano a 
usare svn la prossima volta ritorni con la mazza da baseball (cit. 
multiple). :-) Alle volte e' un metodo che funziona, ma genera molto 
malumore e nessuno comprende ne' l'utilita' di svn, ne' come usarlo 
proficuamente.
A. 

 Comunque, ci sono 2 modi di affrontare il problema:
il terzo modo consiste semplicemente nel prendere il controllo di una 
situazione che a me pare semplicemente scappata di mano.
sarò fissato, ma quello che mi preoccuperebbe in quella situazione non è 
tanto l'uso o meno del svn, quando il fatto che la gente rilascia le 
proprie modifiche direttamente e per conto suo. si tratta di un grande 
generatore di casini.
quando uno spiega che c'è bisogno di fare rilasci organici e gestirne le 
revisioni il resto viene da se, compreso l'uso degli strumenti. come ho 
già detto e ripetuto non puoi spiegare quanto è figo svn se nel processo 
di sviluppo al programmatore non serve. finchè consenti al grafico di 
modificare i file direttamente in produzione è ovvio che un sistema di 
versioning è di intralcio e basta.

 proficuamente.
Un'altra controindicazione che ha e' che qualche sfaticato prendera'
qualche giorno di malattia causa contusioni e fratture. E se trovi un
grafico grande grosso e incazzoso? Il compito sarebbe molto piu'
arduo.
Forse hai ragione, botte da orbi non e' un metodo efficace ...

 mazza da baseball.
Esatto :P
L'ho visto in pratica: tutti ad usare il cvs solo perche' c'era qualcuno li'
con la mazza. Appena la mazza non c'e' stata piu', tutti di nuovo a fare i
beati cazzi propri fino all'inevitabile casino (sputtanamento del codice senza
ritorno).

 arduo.
E' per questo che hanno inventato le armi da fuoco, con una 45 in mano
il grafico puo' essere pure Mike Tyson :-)))))))

 il grafico puo' essere pure Mike Tyson :-)))))))
Sei stato in California?
Durante il grande incendio a Lake Tahoe, un mese fa, un po' di
proprietari di case di legno le bagnavano con irrigatori, tentando di
salvarle.
Il sindaco gli ha proibito di usare l'acquedotto per via della
pressione.
IL tipo, al telegiornale e' stato chiarissimo:
"That's my house. That's the water shutoff valve. And this is a .45...
now try to shut the water off"
P

 la loro utilita' nel lavoro quotidiano.
...oppure ti chiama ogni 3 minuti quando deve fare il commit del proprio 
lavoro su un branch o roba del genere. Per non parlare della fase di 
merging, che tipicamente si risolve in un bagno di sangue. Questo perchè 
è *troppo* faticoso darsi uno sguardo al SVN-book (che, per la cronaca, 
è anche tradotto in italiano...).
Il problema è solo nelle "motivazioni". Io ho iniziato ad usare un 
sistema di controllo di versione (CVS per la precisione) perchè ho 
trovato le mie motivazioni, che erano pressappoco le seguenti:
1 - sarebbe bello poter tenere traccia in maniera automatica delle 
modifiche che faccio al sorgente (categorie "esigenze primarie")
2 - frequentando i vari ng mi sono accorto che molti programmatori 
parlano di CVS, vuoi vedere che è una cosa utile? E poi se tutti la 
usano - o usano un sistema equivalente - un motivo ci sarà, no? 
(categoria "accompagnati con chi è meglio di te e pagagli le spese", 
come dicono le nonne ascolane...).
Quanti programmatori non sanno nemmeno cosa sia usenet? Quanti 
programmatori non reputano affatto importante pianificare l'evoluzione e 
i cambiamenti del codice? Per questo genere di problemi non c'è mini 
corso interno che tenga :-(
Ciao,
Giulio
--
OnAir: J.S.Bach - Sonata per violino in Sol Maggiore