Newsgroup: it.comp.java
Titolo: SVN: ma la sincronizzazione dove sta?

Immaginiamo che sto scrivendo un progetto (composto da 300 src files) 
con una persona. Io modifico foo.java per aggiungerci delle 
funzionalità. Nel frattempo, l'altra persona modifica proprio foo.java 
per aggiungerci LE STESSE funzionalità.
Io farò il primo commit, l'altra persona farà il commit E SOLO A QUESTO 
PUNTO SVN ci informa che il lavoro (e quindi il tempo) che una delle due 
persone ha speso per aggiungere le stesse funzionalità è stato inutile.
Per risolvere questo problema, cosa mi consigliate?
Grazie


Parlarsi ?
--
www.megadix.it


lolllll
In realta' non so SVN ma in CVS che dovrebbe essere la stessa cosa
1. Lock esclusivo ( win cvs / MS sourceSafe / clear case )
Il file non e' editabile da 2 persone assieme
2. Non esclusivo ( eclipse
Si deve fare refresh quasi ogni giorno e allora ci si accorge del conflitto
ciao Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 
Si, ma immagina che a questo punto le persone nel progetto siano 50...


In questo caso serve un coordinatore, e non dirmi che non ce l'avete;
neanche i progetti opensource più freakettoni hanno un coordinatore :)
Passando alle cose serie, ecco cosa dovete fare: il SECONDO developer,
quello che si ritrova il file in conflitto, deve:
- integrare *SE NECESSARIO* le modifiche dell'altro/i, valutando caso
per caso; in questo caso lo strumento più utile è il TELEFONO o meglio
la presenza di entrambi gli sviuppatori nella stessa stanza ;)
- infine indicare a SVN che le modifiche al file sono state "fuse": su
Eclipse si chiama "Mark as merged", su altri client è simile.
A questo punto il secondo developer si ritrova il file semplicemente
come cambiamento in uscita, da committare insieme agli altri.
Con CVS succede qualcosa di simile.
Ciao ciao, Dimitri
--
www.megadix.it

 wrote:

organizzarvi decentemente.
se due persone fanno la stessa cosa, vuol dire che:
1 - una persona ha dato le stesse disposizioni a due persone
2 - i due programmatori sono due schegge impazzite e fanno di testa
loro
in ogni caso svn *non* serve per risolvere questo tipo di conflitti,
il fatto che fornisca strumenti per il merge di modifiche sullo stesso
file non significa assolutamente che lo puoi mettere a guardia di
programmatori che si sovrappongono nel lavoro...

 Si, ma immagina che a questo punto le persone nel progetto siano 50...
e che sono, 50 schegge impazzite?

 persone ha speso per aggiungere le stesse funzionalità è stato inutile.
Il tuo è un problema organizzativo (chi deve fare cosa) che non è 
compito di SVN (o CVS o altro "versioning system") gestire.
Se si tratta di un gruppo piccolo parlatevi, se invece è un gruppo 
grande ci sono sistemi di gestione dei progetti per facilitare le 
comunicazioni e l'organizzazione. In ogni caso non vi potete basare sul 
fatto che un file non possa essere modificato da due utenti 
contemporaneamente.
Il fatto che i file non vengano lockati consente a 2 utenti diversi di 
lavorare sugli stessi sorgenti (magari per modificare 2 parti tra loro 
indipendenti) ed inotre evita problemi come "tizio si è dimenticato di 
rilasciare il lock sul file X che devo modificare. Ora è in ferie e il 
suo pc è protetto da password".
Andrea

 Si deve fare refresh quasi ogni giorno e allora ci si accorge del conflitto
ma un programmatore non può accorgersi dal svn/cvs che il lavoro che
sta facendo in realtà l'ha già fatto qualcun'altro... è un modo di
lavorare da sturmtruppen.

 Con CVS succede qualcosa di simile.
Sì, infatti la lettera 'C' di CVS sta per *Concurrent* e per questo 
sempre meno progetti lo usano... ;)
Subversion è stato creato apposta per evitare di poter utilizzare solo 
l'approccio concorrente (con gli inconvenienti lamentati dall'OP) ma 
permette anche la modalità lock/unlock, in cui un utente può ottenere ed 
editare una risorsa solo se nessun altro l'ha già richiesta in uso.
E' una proprietà che va settata a livello di file con "svn:needs-lock".
Anche perché, sinceramente, mi sembra molto più affidabile un sistema di 
lock che un coordinatore (il caso dell'OP è però estremo: se due persone 
lavorano sulla stessa cosa c'è un problema organizzativo a monte...) :)
Ciao,
Paolo

Michele ha scritto:

In definitiva: ogni utente dovrebbe lavorare su file separati 
concorrentemente?

Michele ha scritto:

No, ogni utente dovrebbe fare cose diverse contemporaneamente. Nulla 
vieta che nel farlo debbano modificare gli stessi file ma non ha senso 
che 2 stiano facendo la stessa cosa nello stesso momento.
Ma è una semplice regola di buon senso! Se 2 muratori devono costruire 
una casa si metteranno daccordo in qualche modo (io faccio questo muro, 
tu fai quell'altro).
Avere un sistema che ti impedisce di modificare un file in modo 
concorrente non ti garantisce da questo genere di problemi. Un esempio: 
2 utenti (Tizio e Caio) vogliono introdurre una funzionalità e per farlo 
devono modificare 2 file A e B. Tizio inizia a modificare A, Caio inizia 
a modificare B e siccome lo fanno senza parlasi le modifiche non sono 
tra loro "coordinate" e quindi ad A non va bene la modifica fatta da B e 
viceversa.
Ribadisco più chiaramente quello che ho detto nell'altro post: tu stai 
cercando una soluzione ad un problema tramite uno strumento che non 
c'entra niente con il tuo problema.
Andrea


Si e' vero :-)
ma in gruppi grossi puo' succedere anche alle migliori famiglie che magari
uno tocca una libreria condivisa senza avvisare, tipico quelle dei dati


 Andrea
Per esperienza succede anche di peggio:
- situazione di cui sopra;
- il grande capo buana ha il "potere" di togliere il lock a chi gli
pare (SourceSafe ad esempio lo consente tranquillamente);
- in qualche modo apporta le modifiche, di solito ad minchiam;
- non va più un ca@#o;
- chiamano il moribondo e lo incetriolano per bene.
In sostanza l'effetto del lock è aumentare i conflitti, e oltretutto
come vedi non elimina le modifiche concorrenti :)
--
www.megadix.it

 
www.megadix.it


 basta ricordarsi di refreshare spesso o al limite fare piu' branch
Nella mia azienda usiamo i lock solo per i documenti in formato binario 
perché fare il merge con documenti binari non è il massimo. Quando uno 
vuole modificare un documento già "lockato" da qualcun'altro chiede a 
quest'ultimo se può rilasciare il lock. I file binari hanno la proprietà 
svn:needs-lock impostata per default.
I file sorgenti invece non sono lockati. Se due persone modificano lo 
stesso file uno dei due dovrà semplicemente fare il merge prima del commit.
Per quanto riguarda il coordinarmento delle persone c'e' un project 
manager che decide in che ordine implementare i casi d'uso e a chi dare 
il compito di implementarli.

Per risolvere questo problema, cosa mi consigliate?
Perdonami Michele, ma la tua domanda non ha senso.
O meglio: un senso ce l'ha, ma la risposta è svincolata da SVN.
SVN non può leggere le intenzioni nella mente dei programmatori, può
solo segnalare (come qualsiasi altro software di versioning)
conflitti, qualora vi siano. Tantomeno può risolvere i problemi
organizzativi di un'azienda. Quello che, al massimo, potete fare tu e
il tuo collega è di organizzare il lavoro in modo da non pestarvi i
piedi a vicenda. La tua domanda non è ammissibile neanche in un
contesto di 50 programmatori (contesto in cui io ho lavorato con lock
"ottimistici" come quelli di default di CVS/SVN senza alcun problema).
Ti dò un consiglio: Microsoft Project :-)

neanche i progetti opensource più freakettoni hanno un coordinatore :)
Credi davvero che questa eventualità sia così improbabile?
Stai attento prima di buttarti in una risposta :-)

pare (SourceSafe ad esempio lo consente tranquillamente);
Humm... io ho usato SS in team e non è mai successa una cosa del
genere... nel senso che non abbiamo mai consentito a nessuno di agire
a livello superiore a tutti gli altri; almeno, che io ricordi, non con
tutta questa disinvoltura.

 concorrentemente?
no, non è necessario.
gli utenti *possono* modificare dei sorgenti in concorrenza, perchè ci 
sono strumenti per fare il merge delle modifiche e anche per risolvere i 
conflitti.
quello che tu hai paventato è un'altro problema, cioè che due utenti non 
solo modificano lo stesso sorgente ma si sovrappongono il lavoro.
-- 
Fino all'anno scorso avevo un solo difetto. Ero presuntuoso.
http://softvalley.blogspot.com

Andrea Laforgia ha scritto:

Ciao Andrea e grazie per la risposta molto chiara,
in pratica sto sbagliando: io e il mio collega dobbiamo coordinarci: 
ognuno deve lavorare sugli stessi file, ma non concorrentemente. Corretto?
Grazie

 ognuno deve lavorare sugli stessi file, ma non concorrentemente. Corretto?
no, non hai capito...
tu e il tuo collega vi dovete semplicemente mettere d'accordo sui task, 
in modo che non vi ritroviate a fare le stesse modifiche, le stesse 
correzioni o esaudire le stesse richieste. questo è il vostro problema. 
non le modifiche concorrenziali sugli stessi file, le quali sono 
tecnicamente gestibilissime.


 lavorano sulla stessa cosa c'è un problema organizzativo a monte...) :)
non è vero. si possono fare moltissimi esempi di casi dove è normale 
modificare in più di uno lo stesso file, si va dai file di 
configurazione (struts-config.xml, application-context.xml, etc...) ai 
file di properties dei messaggi i18n.
personalmente non ho mai ritenuto necessario ricorrere a sistemi di 
lock, anche in gruppi numerosi e disomogenei. in un caso dove lavoravamo 
in quattro società diverse facevamo uso intensivo dei branch (che poi 
andavano sistematicamente riportati sul trunk), ma i lock esclusivi sin 
dai tempi in cui usavo vss con visual studio 2003 li ho sempre 
considerati un fastidioso e inutile bastone fra le ruote. lo 
sviluppatore deve lavorare, non aspettare che gli rilascino il file da 
modificare.


ognuno deve lavorare sugli stessi file, ma non concorrentemente. Corretto?
Correggo un po' il tiro del mio precedente messaggio:
Diciamo che, se c'è il rischio che la modifica che stai facendo possa
apportarla nel frattempo anche il tuo collega, sì, la soluzione è
questa e la ottieni con un lock pessimistico (i.e. metti in stato edit
il file, impedendo a chiunque altro di modificarlo).
Dovrebbero però essere rare eccezioni, queste. In generale, infatti,
non ti conviene lavorare così. I lock di questo tipo fanno a cazzotti
con contesti di multiutenza. Il problema (ovvio) è che finquando non
rilasci il file, nessuno può toccarlo, neanche per apportare modifiche
che non sono in conflitto con le tue.
Chiariamo che, con qualsiasi tool di versioning, DEVE essere possibile
lavorare concorrentemente sullo stesso file, perché l'opposto sarebbe
decisamente troppo limitante, come vedi. 
Esistono poi linguaggi (e Java è uno di questi) in cui unità minime
del codice, come le classi, vengono isolate in singoli file e questo
rende meno probabile la necessità di lavorare sullo stesso file, però
di certo non l'annulla. E' infatti possibile che due programmatori
compiano modifiche alla stessa classe. Nessun problema, a livello
concettuale.
I sistemi come SVN sono evoluti al punto da capire se ciò che il
programmatore A ha fatto entra in conflitto con ciò che il
programmatore B ha fatto (essenzialmente se hanno toccato le stesse
righe originali) e nel caso segnalarlo. Se non è così, il merge delle
modifiche viene compiuto automaticamente senza problemi.

correzioni o esaudire le stesse richieste. questo č il vostro problema. 
Perň mi rendo anche conto che ci possono essere contesti in cui piů
sviluppatori non riescano a comunicare facilmente tra loro (parlo di
problemi prettamente tecnici, ovviamente non umani :-) e in questo
caso, forse, un lock pessimistico puň rivelarsi una soluzione piů
agevole.

 viceversa.
Ma più divertente ancora:
Tizio comincia a modificare A, ma si rende conto che per continuare deve
modificare B. Caio deve comincia a modificare B e si rende conto che per
continuare deve modificare A.
-> Applicare algoritmo di risoluzione dei deadlock a scelta.
Possibilmente in modo cruento. <g>
-- 
cc = callcc {|cc| cc.call cc}; cc.call cc

 lavorano sulla stessa cosa c'è un problema organizzativo a monte...) :)
Guarda, io posso dirti che ho usato per lungo tempo CVS. Poi sono
passato ad svn. Caruccio eh, anche solo il rename ti farebbe venire
voglia di passare a svn.
Poi pensandoci bene ci sono più cose in cui fra esperienza nel team,
facilità di gestione e tutto preferisco cvs (oltre che velocità). Ma il
problema non si pone:
da quando uso mercurial mi si è apero un nuovo mondo stupendo. Ah, però
non mi è mai capitato di lavorare in team di 50 persone completamente
anarchici dove la gente modifica files di nascosto. :)


 Possibilmente in modo cruento. <g>
Dopo accurata analisi mi sento di aggiungere che se di decide di
scagliare dalla finestra uno o più fra Tizio e Caio con la relativa
postazione di sviluppo, si consiglia di ricordarsi di rilasciare i lock
in precedenza. Le due operazioni non commutano.


 lock, anche in gruppi numerosi e disomogenei.
Neppure io, visto che a monte c'era una schedulazione dei lavori ben 
precisa (qualche problema talvolta si è verificato, ma nulla di serio).
 > lo sviluppatore deve lavorare, non aspettare che gli rilascino il file
 > da modificare.
Vero, ma deve anche essere in grado di verificare se altri stanno 
modificando lo stesso file e valutare di conseguenza.
Ciao,
Paolo

 da quando uso mercurial mi si è apero un nuovo mondo stupendo.
A mercurial sto dando un'occhiata pure io... ;)
Ciao,
Paolo

 anarchici dove la gente modifica files di nascosto. :)
A volte non sono neanche gli strumenti ad aiutarti. Per esempio, ho usato
un tool per la gestione dei package Oracle che non ti avverte di possibili
conflitti tra più utenti (in realtà non può farlo), con il rischio ovvio
di sovrascriversi a vicenda le modifiche... :-(
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 di sovrascriversi a vicenda le modifiche... :-(
Immagino non ci fosse scelta.


 dopo che è fallita la 'prova svn'
Curiosità : qual'è il motivo per cui è fallita ?
Ciao e grazie,
    Davide
--
davide...@mclink.it

 Curiositą : qual'č il motivo per cui č fallita ?
Lo hanno trovato eccessivamente lento, principalmente.
Per il resto non ha offerto nulla che non avessimo sotto CVS.


 Per il resto non ha offerto nulla che non avessimo sotto CVS.
La nostra esperienza è stata completamente differente, infatti adesso 
abbiamo convertito i repository di tutti progetti attivi da CVS a SVN.
In particolare ci è piaciuto il fatto di poter rinominare i file e 
spostare le directory.
Un'altro vantaggio che ci è piaciuto è il fatto che subversion è molto 
piu' veloce nel farti vedere le differenze tra la working copy e la 
working base (quella sul repository).
Senza contare l'interfaccia grafica TortoiseSVN che abbiamo tutti 
trovato molto piu' comoda di WinCVS che utilizzavamo prima.
De gustibus....

 De gustibus....
esiste anche tortoiseCVS e TortoiseHg.
ma a parte questo hai detto bene, degustibus. quando ho visto che ad
ogni modifica svn revisiona tutto il progetto sono rimasto un
capellino perplesso, senza contare come gestisce branch e tag.
indubbiamente svn va bene per un gruppo che sviluppa in modo lineare
sul ramo principale del progetto, ma se il gruppo fa uso di branch,
tag e relativi merge svn ti fa perdere la testa.

 esiste anche tortoiseCVS e TortoiseHg.
mmmmmm
tortoiseCVS lo ho installato, mi ha destabilizzato del tutto il mio
"stabilissimo" windows xp .... e lo ho levato al 30esimo minuto :-)
Magari lo ho installato male o non lo conoscevo a sufficienza ma non ho
avuto una buona esperienza.
ciauz Nicola


 avuto una buona esperienza.
non penso sia così tanto più instabile dell'omologo per svn... anzi,
mi risulterebbe più maturo.
in ogni caso era una annotazione di servizio, io non lavoro su
windows.

 De gustibus....
Chiaramente. I log in mail come li avete risolti?


 mi risulterebbe piů maturo.
Anni fa lo avevo usato e non mi aveva dato problemi. Ne lui ne
tortoisesvn.


 I log in mail come li avete risolti?
Cosa intendi? Mandare il messaggio di ogni commit via mail a qualcuno?
Non facciamo una cosa del genere.

 Per il resto non ha offerto nulla che non avessimo sotto CVS.
Grazie per la risposta ... e per tutti i reply che son scaturiti.
Ciao,
    Davide
--
Ing. Davide Grandi
davide....@mclink.it

 secondi per gli update) viene un po' da interrogarsi.
infatti, va visto poi quanto queste features sono utili e quanto costano.
svn è velocissimo nel fare i confronti con le versioni precedenti perchè 
in realtà le versioni precedenti se le porta nella working dir. a parte 
il costo, ma qual'è la vera utilità? lavorare offline? bah...


 il costo, ma qual'è la vera utilità? lavorare offline? bah...
Io lo trovo molto utile prima di fare commit rivedo cosa ho cambiato 
rispetto alla versione precedente così posso scrivere un commit message 
piu' chiaro.
Chi ha progettato ha preferito spendere un po' piu' in spazio disco e 
risparmiare in trasmissioni di rete. Infatti nella working copy hai 
semrpe una cartella .svn una versione dei file aggiornata all'ultimo 
update (working base) e per questo vedere le differenze è molto veloce.
Secondo me hanno fatto veramente bene a scegliere questo tipo di 
approcio. Sulla documentazione ufficiale hanno giustificato la scelta 
dicendo che oggigiorno i prezzi dei dischi si sono abbassati mentre la 
connessioni di rete sono abbastanza lente da farti aspettare troppo.
Diversamente con CVS vedere le differnze era molto meno immediato.

 tag e relativi merge svn ti fa perdere la testa.
Non capisco, cosa ci sia di complicato. A me e ad altri che conosco che 
usano i tag e i branch non succede di perdere la testa.
Certo l'uso dei tag e dei branch non è lo stesso di quello di CVS, forse 
per uno che conosce CVS capire il sistema che usa Subversion può essere 
complicato all'inizio ma una volta imparato non ci sono problemi.
Se mi stai dicendo che con i tag e i branch di CVS si possono fare cose 
che con SVN non si possono fare allora è un'altro discorso.
O forse mi stai dicendo che i tag di CVS sono molto piu' semplici da 
usare di quelli di SVN?

 
Per linux penso che non esistano client Subvesion piu' efficaci che 
quello ufficiale da linea di comando svn. Ho provato parecchi client 
grafici per linux ma non danno quasi niente in piu' della linea di comando.
Al contrario il client TortoiseSVN che esiste solo per windows lo trovo 
troppo comodo.

 modificati in modo non coerente.
ma questo è un problema di svn, è lui che si prende la briga di fare una 
revisione di tutto il progetto ad ogni commit.
non vedo la necessità di avere rigorosamente ad ogni istante una 
situazione coerente sul repository. quando si può tirare una riga 
orizzontale lo stabilisce l'uomo e ci sono gli strumenti per farlo, 
altrimenti a che servono i tag?


Andrea Francia ha scritto:

beh, non sono un maniaco della linea di comando, perň in java (per 
tornare in tema) uso eclipse che si interfaccia in modo molto piů che 
adeguato con cvs e svn.
tortoise l'ho visto, l'ho anche usato, č indubbiamente carino ma 
sviluppando in java non ne sento affatto la mancanza.


 altrimenti a che servono i tag?
Sempre che l'uomo faccia questo lavoro. Mi è capitato di ereditare 
repository CVS dove questa cosa non era stata fatta e dove l'uso dei 
branch è stato fatto un po' a capocchia.
Il mio problema era capire da quale punto in poi era stato creato un 
branch e da quale punto era stata aggiunta una certa feature per 
portarla sul ramo principale.
Analizzare il repository con CVS è stato un incubo perché ogni file ha 
il suo numero di versione che viene incrementato in modo indipedente 
dagli altri.
Convertendo il repository da CVS a SVN ho risolto i problemi perché sono 
riuscito a capire esattamente quando il ramo si è staccato dal tronco e 
altre cose.
Se chi aveva il progetto in mano prima di me avesse usato una politica 
chiara e decente per gestire il controllo di versione io non avrei avuto 
bisogno della caratteristicha di SVN di usare lo stesso numero di 
revisione per tutti i file del progetto e sarebbero bastati i tag come 
dici tu.

 non sono consistenti. qual'č il senso di questa cosa?
Non capisco che senso abbia dare un commento su ogni file?
Il commento serve a *mio* modesto parere a indicare le modifiche tra la 
versione precedente e quella successiva.
In questo modo chi vede l'eleno delle revisioni puo' capire in modo 
semplice quando una certa feature o modifica architetturale č stata 
implementata.
Alla fine hai 9 revisioni incosistenti perché hai fatto 9 commit 
inconsistenti non perché il modello di repository di SVN ha qualche 
problema logico.

 branch è stato fatto un po' a capocchia.
adesso non voglio entrare nel merito del tuo caso perchè sicuramente 
avrai avuto le tue difficoltà, e comunque le cose a capocchia si possono 
fare con qualsiasi strumento. io dicevo un'altra cosa.


 altrimenti a che servono i tag?
Ti riferisci alla cartella tags?

 Ti riferisci alla cartella tags?
anche si, nel caso di svn.
qualunque sistema che consenta di fissare uno snapshot.


 problema logico.
sono 9 revisioni del progetto che svn ha storicizzato inutilmente.


 sono 9 revisioni del progetto che svn ha storicizzato inutilmente.
Qualsiasi sistema di controllo di versione lo fa se fai 9 commit inutili.

 
Ma quella serve per comodita'.
Se vuoi i sorgenti della release 1.2.23 scaricateli dal tags 
release.1.2.23 niente di piu'. Tanto e' vero che gli stessi identici 
sorgenti si trovano in qualche storia del trunk.
Sul server ovviamente non occupa alcuno spazio.

 Ma quella serve per comodita'.
si si, siamo d'accordo. intendevo quella :-)


 
Per cui anche tu la trovi utile ora...

 Per cui anche tu la trovi utile ora...
scusa, ma non ho ben capito quando avrei detto che non è utile...


 Qualsiasi sistema di controllo di versione lo fa se fai 9 commit inutili.
no, aspetta, cosa c'entrano "9 commit inutili"? io committo 10 file 
diversi, solo che invece di farlo in un unico botto lo faccio in piů 
volte. di inutile non faccio niente.


 volte. di inutile non faccio niente.
Riformulo: Qualsiasi sistema di controllo lo fa se fai 10 commit come 
hai detto tu.

 hai detto tu.
no. qualsiasi sistema aggiungerebbe una nuova revisione ai file 
modificati, non dieci revisioni a tutto il progetto.


 modificati, non dieci revisioni a tutto il progetto.
E qual'č il problema? Aumenta un contatore e allora? I CVS ci sono tanti 
contatori quanti sono i file e ognuno viene incrementato di uno. In SVN 
c'e' un solo contatore e viene incrementato di uno dieci volte di seguito.

 E qual'è il problema? 
vabbeh, non è che posso ripetermi ad oltranza. l'ho già detto che *a* 
*mio* *avviso* non è comprensibile. non siamo d'accordo, va benissimo così.


 
in effetti..ho letto male. Pensavo "siccome ci sono i commit atomici i 
tag non servono". Ma non l'hai scritto.

 
Questo significa che mentre usi SVN pensi di utilizzare qualche altro 
tool. Il problema rimane tuo. Cosa di ferma dal fare un commit unico?

 tool. Il problema rimane tuo. 
ho sollevato una critica su un aspetto, è ovvio che se non mi sta bene 
il problema rimane mio...


 
Si ma stavamo chiedendo un caso d'uso dove tu sei costretto a committare 
9 file distinti invece di farlo in una botta sola. E questo nel giro di 
pochi secondi / minuti.

 Cosa intendi? Mandare il messaggio di ogni commit via mail a qualcuno?
Yep. Per noi è una cosa sostanzialmente fondamentale.
-- 
cc = callcc {|cc| cc.call cc}; cc.call cc

 
Noi non lo facciamo ma credo che si potrebbe fare.
Penso che basti mettere nello script di hook post-commit un comando che 
manda la mail a chi vuoi.

 manda la mail a chi vuoi.
Se ci si riprova, passerņ voce.


 Per risolvere questo problema, cosa mi consigliate? Grazie
Svn permette di mettere un "lock" sul file questo non risolve tutto ma fa 
perlomeno venire un "dubbio" a chi va a prendere un file per modificarlo.