Newsgroup: it.comp.os.linux.sys
Titolo: Server svn

Un consulente mi ha chiesto di mettergli sù una macchina con un servizio di svn 
per sviluppare alcuni software per la nostra azienda.
Lurkando qui e là ho sentito parlare di GIT ultimamente e leggevo che era 
compatibile anche con svn perciò pensavo di mettere sù quello.
Lui mi ha detto solo che accederà attraverso dei plugin svn da eclipse.
 
Avete consigli per evitare di fare delle cavolate?
 
Grazie
Rizio
 
--- Posted via news://
freenews.netfront.net/
 - Complaints to 
ne...@netfront.net
 ---

 Avete consigli per evitare di fare delle cavolate?
 
Mettigli un (il) server svn.
 
Bye.


Se ti ha chiesto svn, mettigli svn...
 

 Se ti ha chiesto svn, mettigli svn...
 
Ok, grazie a tutti e due.


 Avete consigli per evitare di fare delle cavolate?
 
Spiegagli perche` Git e` meglio di Svn (in primis, Git e` piu` veloce), 
altrimenti lascia perdere ed usa il prodotto richiesto dal cliente
 
Enrico

 altrimenti lascia perdere ed usa il prodotto richiesto dal cliente
 
Non essendo sviluppatore non s� le differenze tra git e svn (oltre a quelle che 
potete indicare qui) di conseguenza penso che metter� s� svn e taglio la testa 
al toro.
 
Ne approfitto per farti una domanda riguardo a svn: il plugin su eclipse quali 
metodi di accesso usa al repository? Devo configurare per forza Apache (come st� 
leggendo su tanta doc o pu� accedere attraverso un'interfaccia sua (fornita da 
un demone X sulla porta Y)?


 un demone X sulla porta Y)?
 
SSH e vai tranquillo!
Puoi anche configurare l'utente (come ho fatto io) per permettere SOLO
l'uso di SVN e segare via tutto il resto che si puo' fare via SSH.
Nel mio caso (ci sono sicuramente anche altre possibilita') ho
semplicemente impostato la Shell dell'utente a questo script:
 
#!/bin/sh
 
if [ "$TERM" = "" ]; then
  /usr/bin/svnserve -t
else
  /bin/echo "L'utente e' autorizzato solo per l'uso di SVN"
fi
exit
 
Ciao
Luca Bertoncello
(
luca...@lucabert.de
)
 
-- 
 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it
 
 
 

 semplicemente impostato la Shell dell'utente a questo script:
 
Ok, grazie mille. Tengo presente lo script.


Io preferisco Mercurial a GIT, è più simile a SVN.

un demone X sulla porta Y)?
 
svnserve sulla porta 3690/tcp. Per me, numero uno! :-D
 
Leonardo
 
-- 
Tell us whether you spy, in the light of the morn,
what saluted was fiercely at the fall of the past day:
whose pips and whose bands in the very heart of the fray
bravely floated from the bulwarks to which we were sworn?

 svnserve sulla porta 3690/tcp. Per me, numero uno! :-D
 
Ottimo!!!! Così mi piace un sacco, nemmeno ssh devo abilitare!
Bellissimo, grazie mille
 
Tnk's


Ottimo!!!! Così mi piace un sacco, nemmeno ssh devo abilitare!
 
Ma ricorda: SSH è buono. SSH è tuo amico. SSH fa bene :-D


 Ma ricorda: SSH è buono. SSH è tuo amico. SSH fa bene :-D
 
Si mio Jedi :D
Il fatto è che non voglio nemmeno dargli quella possibilità lì. Lo script di 
Luca mi è sembrato molto buono però mi piace molto di più non dargli nessuna 
chiave privata per l'accesso ;)
 
Tnks'


 chiave privata per l'accesso ;)
 
Guarda che il mio script funziona perfettamente anche con le password, eh?
In effetti, in ditta, io sono l'unico ad usare le chiavi per autenticarmi
(anche perche' la maggior parte delle altre persone pensa che la chiave
sia solo quella per aprire la porta).
 
E, password per password (visto che anche con svnserve una password la
dovresti usare), sinceramente preferisco SSH, che mi consente un controllo
piu' approfondito e, per giunta, una comunicazione criptata...


 sia solo quella per aprire la porta).
 
Be', in un certo senso ... ;-)
 
 
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net
 

 sia solo quella per aprire la porta).
 
se gli informatici "aprono le porte" devono ben "usare le chiavi"
vi pare ?


 sia solo quella per aprire la porta).
 
Si, non intendevo quello, mi sono spiegato male.
Io intendevo dire che preferisco non dargli accesso ssh (in azienda accedo ai 
server solo con chiavi ssh) ed esporre solo svnserve, tutto lě, non discutevo altro.
 
 
Ciao


sia solo quella per aprire la porta).
 
Ciò mi ricorda uno scambio memorabile ("Hai una chiave privata?" "Sì, la
tengo in un finto vaso dietro il garage").


 può accedere attraverso un'interfaccia sua
 
Puoi sia usare un demone che il modulo Apache. Personalmente 
preferisco quest'ultimo metodo, in quanto mi permette di sfruttare i 
metodi di autenticazione forniti dal web server (e.g. per i repository 
dove mi interessa, uso l'LDAP dell'ufficio via Apache per autenticare)
 
Enrico

 Le differenze sono architetturali.
 
Dimenticavo. Tieni presente che Subversion ha problemi prestazionali, 
ovvero in caso di repository grossi[1] puoi avere delle attese di ore per 
il checkout (ma hai problemi anche per gli update). In teoria con la 1.7 
hanno risolto, ma dubito che si vedra` presto nelle distribuzioni e sui 
client...
 
Enrico
[1] e, considerando che un tbz2 di tutti i dump subversion dell'ufficio 
(di cui quelli attivi sono tre) stamani occupava 11Gb, direi di avere una 
vaga idea su cosa significhi grosso :)

 rispetto a quelli possibili con un VCS centralizzato
 
Inoltre se si è abituati a svn con un DVCS si puo' comunque non 
sfruttare il livello in più che viene offerto riprodurre  il regolare 
flusso di lavoro (modifica, commit), in questo senso il passaggio a 
mercurial è praticamente senza trauma.

 client...
 
La 1.7 me la sono ricompilata; troppo comodo fare a meno delle directory 
nascoste ".svn" in ogni sottodirectory!
 
Purtroppo ho timore a istallarla sul server svn; ho paura che l'archivio 
abbia un formato diverso (sul client č cosě).
 
Prima o poi farň un export e, successivamente, un import
 
Alessandro

 Prima o poi farò un export e, successivamente, un import
 
Beh, quello dovrebbe essere semplice da fare, se hai un dump notturno del 
repository (che, spero bene per te, tu abbia ;) )
 
Enrico
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
 
iQEcBAEBAgAGBQJO4NkqAAoJED3SMOGZLYdYtE4H/Rv4GLBQFgadZjM+RAF2Zqhn
tP/jhQbA9B+xa8C7zF51GkLyFuP2WBfqjGwG2b1Yu8LnEiDjUGbcklECM0SL3Z68
VqZCNGippuhH/QgoVdfYHd/3+9yh+vmEMRfqfSEVrqzpwanGl/JAF4+0nqAoZfDd
zqEqCvk72a/sWkUt7XokGmwhHy33PjvAmpFiRZsY6p+9hM+KBG9IkYXGJJTpowp5
RYx6rK/D1a7WyzswLnuNGkq77RM+exhFOOV99UCBOid+pB/dh2Xn/Rd2c7QVQVOy
oS74DP/2cnUijqVUTaQt7PEFovxAOulBNcQuXlW6fpOOUAGGgGTTJsbmvLXAmY8=
=dUrt
-----END PGP SIGNATURE-----
 

 chiavi ssh) ed esporre solo svnserve, tutto lì, non discutevo altro.
 
svn+ssh, webdav o svnserve presentano le stesse funzionalità, alcuni 
vantaggi ed alcuni svantaggi.
Nessuno di questi però fornisce accesso in SSH alla console.
 
Se uno si leggesse esempi o documentazione noterà che ci sono i metodi 
nativi di ssh (normalmente sconosciuti) per limitare l'accesso alle shell 
e che svn+ssh è altrettanto sicuro.
 
Basta googolare, vengono fuori subito.

 repository (che, spero bene per te, tu abbia ;) )
 
Si; più che un dump ho proprio una sincronizzazione notturna tra due 
server svn.
 
Ale

 Basta googolare, vengono fuori subito.
 
Come sopra.... purtroppo non subito ;)
 
Grazie a tutti
