Newsgroup: it.lavoro.informatica
Titolo: SVN - Quale usare e perché?

Visto che l'altra discussione si è animata solo su quello e visto che 
mi interessa (a prescindere se dovrò decidere qualcosa o meno):
quale usare? perché?
quale non usare? perché?
 
Partiamo con un progetto nuovo quindi nessun vincolo legacy e nessun 
tipo di fissazione mia: banalmente conosco solo Tortoise (ma non è un 
problema).
 
TORTOISE?
MERCURIAL?
GIT?
altro?
 
 
Grazie :)
 
-- 
«Non scegliere la strada più comoda, scegli quella giusta.» (Al3xI98O)

 Grazie :)
 
sappi che ti distruggeranno :)
-- 
Soprano


Lol. ha deciso di plonkare alcuni buoni del ng (non il sottoscritto 
ovviamente) da cui avrebbe solo che da imparare.
 
Questi i risultati :D

Soprano in data mercoledì, 19/07/2017 ha detto:

Ad occhio non li leggo quelli :)


 sappi che ti distruggeranno :)
 
(scusa partito il pos!)
E cmq io sto chiedendo a chi (forse) ne sa di più... se hanno problemi 
possono non leggere, non rispondere, andare a prendersi un gelato... ;)


 E cmq io sto chiedendo a chi (forse) ne sa di più...
 
Visto che ha scelto di sua volonta' di rotolare nella sua cacca, mi 
parebbe corretto non spiegargli come stanno le cose.
 
Che studi da solo visto che e' tanto arrogante.

 quale usare? perché? 
 
Io utilizzo Mercurial perchè venendo da SVN aveva una sintassi più simile ed intuitiva.
Per un periodo mi ero fissato di usare bazaar (
http://bazaar.canonical.com/en/
), ma purtroppo credo che sia un progetto morto.
 
Se avessi tempo, vorrei provare Fossil (
https://www.fossil-scm.org/
), per i miei scopi potrebbe avere un senso.

 Questi i risultati :D
 
La risposta alla sua domanda comunque e` semplice: non scegliere la strada 
più comoda, scegli quella giusta!!
 
l bello e` che nel suo blog cita uno dei suoi quattro pilastri come 
l'avanguardia tecnologica :)
 
E continua a chiamarlo "tortoise".
 

 quale non usare? perché?
 
 
Scusa ma se usi Visual Studio perché non usi Team Services?
https://www.visualstudio.com/it/team-services/compare-features/?rr=https%3A%2F%2Fwww.google.it%2F
 
 
 
Ciao
  Francesco

 Grazie :)
 
tortoise non c'entra nulla, è solo un front-end grafico, per svn e non so 
quali altri (ricordo tortoisesvn e tortoisecvs, roba del secolo scorso).
 
fossi io sponsorizzerei l'installazione privata di gitlab-ce:
https://about.gitlab.com/features/
 
c'è l'immagine docker:
https://hub.docker.com/r/gitlab/gitlab-ce/
 
 
con un colpo solo porti il gestore dei sorgenti (git), l'issue tracking, 
poni le basi per la continuos integration, un workflow efficiente e altro 
ancora.
 
inoltre: tu hai detto di lavorare su strumenti microsoft, possibile non 
abbia mai sentito parlare dei visual studio team services? 
https://azure.microsoft.com/it-it/services/visual-studio-team-services/
 
 
ad ogni modo, senza polemica, da una parte dici che ti hanno assunto 
anche per decidere e dall'altra mostri di averne esperienza e conoscenza 
sul tema prossima allo zero. non senti anche te stridere? se putacaso ti 
facessero decidere, git piuttosto che mercurial, poi chi insegna al team 
(te compreso, a questo punto) ad usarlo come deve essere usato?
 
 
 
 

Francesco Da Riva in data mercoledì, 19/07/2017 ha detto:

Lo sto chiedendo "a voi" :)


 miei scopi potrebbe avere un senso.
 
Questo mi sfugge completamente... lo guardo :D


 Visual Studio...
 
Niente, 'gna fa.

 Visual Studio...
 
Ma che cazzo dici! :D Ma possibile che tu non conosca nemmeno i tool che usi? 
Che cosa sarebbe TortoiseSVN server? :D

 Server e Client. 
 
posti il link di questo tortoise server, per piacere?

 Lo sto chiedendo "a voi" :)
 
 
Trattavasi di forma retorica :-)
 
Guardalo, credo possa essere una ottima idea per gestire tutto, non solo il versioning.
 
Io uso la versione basata su Azure che da anche qualche altro vantaggio collaterale.
 
Ciao

 Trattavasi di forma retorica :-)
 
Certo ;) L'ho messo tra i preferiti da vedermi in treno :)


 ancora.
 
Carino questo, non lo conoscevo.
Per l'OP: avrei suggerito git ma anche li'...per
scegliere con coscienza bisognerebbe conoscere un
po' tutti i sistemi di revisione piu' usati e poi
la dimensione, esigenze, modus operandi ecc del gruppo
che deve collaborare.
Io ho lavorato bene anche con SVN. Non credo ci sia
"un migiore" altrimenti non ne esisterebbero diversi.
 

 "un migiore" 
 
un migliore, pardon.
 

 "un migiore" altrimenti non ne esisterebbero diversi.
 
Il motivo per cui ne esistono diversi e` principalmente perche` uno 
viene dopo l'altro ed e` troppo complicato portare vecchi sistemi su un 
nuovo vcs se non c'e` una necessita` reale. Questo non significa che 
tutti siano allo stesso livello. L'impossibilita` di creare pull 
requests nel mondo SVN, per esempio, e` a mio parere un grosso limite e 
rende lo sviluppo con SVN qualitativamente di gran lunga inferiore a 
quello che puoi fare con i vari workflow git-based.
 
 

 quello che puoi fare con i vari workflow git-based.
 
 
Si, utilissima funzionalita', magari pero' se ne sente l'impatto
su gruppi numerosi o magari non a stretto contatto.
Anche l'idea di pensare piu' in termine di modifiche e non di revisioni
e' credo sia migliore e piu' efficiente.
Pero', anche tu concepisci il fatto che possa non esserci una
"necessita' reale". Io riformulerei dicendo che puo' capitare anche
che la migrazione non ne valga lo sforzo, suggerendo che i vantaggi
non sono sempre cosi' notevoli.
Per fare un esempio, per gruppi di lavoro non numerosi, che lavorano
a stretto contatto e  solitamente stanziali la differenza di
rendimento si riduce e magari un semplice SVN puo' risultare
addirittura piu' pratico.

 "un migiore" altrimenti non ne esisterebbero diversi.
 
Maronna quanto odio questa affermazione! :)
 
Troppo spesso si pensa che ogni strumento (tool, linguaggio, eccetera) 
abbia un suo perche', un caso d'uso che lo rende migliore degli altri in 
certe situazioni.
 
In realta' e' possibile che ci siamo semplicemente strumenti migliori e 
peggiori.
 
Esempio: SVN e' peggiore di Mercurial. Tirami fuori un solo motivo 
OGGETTIVO per cui dovrei preferire il primo al secondo (esclusa quindi 
legacy e conoscenza pregressa dello sviluppatore).

 addirittura piu' pratico.
 
Ritengo Mercurial (sara' lo stesso per git) superiore in qualsiasi 
condizione. Serve centrale o no, sviluppo locale o no, team grande o 
ristretto.
 
Per quale motivo uno dovrebbe impararsi svn oggi nel 2017? Quello che 
posso fare con svn lo posso fare con mercurial e meglio, ma non viceversa.
 
Non vale neanche l'affermazione che Mercurial da di piu' con maggiore 
complessita', perche' e' davvero facile da utilizzare.

 addirittura piu' pratico.
 
Dubito molto che SVN possa mai essere piu` pratico di git, se non altro 
perche` git puo` dare quel che SVN da`; il contrario non e` possibile.
 
 

 legacy e conoscenza pregressa dello sviluppatore).
 
Io quelle cose tra parentesi le volevo comprendere nel ragionamento.
Mi devo essere espresso male. Al netto di tutto penso
anche io siano preferibili git o mercurial.

 anche io siano preferibili git o mercurial.
 
Quelle cose fra parentesi valgono in qualsiasi contesto. E' tautologico 
dire "se conosco x e non y, e non voglio imparare y per partito preso, x 
e' preferibile".
 
Mi spieghi che contenuto informativa avrebbe un affermazione del genere?

 altrimenti non ne esisterebbero diversi.
 
beh non è del tutto vero. git e mercurial sono delle evoluzioni rispetto 
ad svn, hanno introdotto dei plus senza togliere di fatto nulla alla 
operatività. 
per dire, se vuoi lavorare con git alla maniera di svn lo puoi fare, il 
viceversa assolutamente no.
 

 Certo ;) L'ho messo tra i preferiti da vedermi in treno :)
 
 
Puoi leggere anche qui una introduzione a Mercurial.
http://hginit.com/
 
 
 
Ma sia con Mercuria che con Git devi impostostare una filosofia di 
utilizzo alla quale tutti gli sviluppatori si devono adeguare...
 
io ad esempio, avendo piccoli progettini personali, ho solo il TRUNK 
principale.
 
Se avessi una situazione complessa di rilasci di versioni, necessità di 
supportare versioni vecchie, gruppi di lavoro che sviluppano features 
tangenzialmente alla manutenzione base del prodotto, utilizzerei una 
organizzazione a branch... e anche su questo potremmo starci le ore a 
disquisire su quale sia la migliore strategia che si possa applicare 
alle TUE esigenze...
 
Da quella introduzione vedi quello che può essere fatto con mercurial e 
in modo simile con git.

 modo simile con git.
 
Eh... questo è complesso. Se fosse (ribadisco che sono mie seghe 
mentali nel caso non usino nulla) non sarebbe un problema per le 
persone (all'inizio solo io e poi 2 junior nel 2018... poi chissà ma 
cmq persone nuove) quanto per pensare correttamente già dall'inizio 
cosa potrà succedere :)
Per ora non credo avremo una situazione complessa ma molto lineare 
però... cmq farò in tempo con alcune riunioni già prima del 21/08 a 
farmi delle idee :D


 farmi delle idee :D
 
Qualcuno capisce che ha scritto?
 
 


Speravo nel tuo supporto, o magari una replica dalla quale dipanare il 
senso delle parole in liberta'.


Beh, ricordati sempre che l'importante non e' cadere, ma sapersi 
rialzare. Piu' o meno. :D

On Thu, 20 Jul 2017 17:44:34 +0200, Dr.UgoGagliardelli wrote:
 
[..]


 rialzare. Piu' o meno. :D
 
Hai ragione. Che stupido, stavo quasi per scegliere la strada piu` comoda 
invece che quella piu` giusta. 
 


E se quella piu' comoda dovesse essere anche quella piu' giusta?
Due piccioni con una fava.

Io in data giovedì, 20/07/2017 ha detto:

Quei due lì giusto due picioni posso essere :D


 Due piccioni con una fava.
 
No, scritta come l'ha scritta lui, o e` l'una o e` l'altra cosa. Inutili 
i tentativi di convincerlo che ha scritto una cagata.
 

 Quei due lì giusto due picioni posso essere :D
 
Quindi, a rigor di logica, tu saresti la fava.
Non fa una piega.
 


beh nell'ambito delle soluzioni visto che quella più comoda è generalmente anche la più semplice occam non lo escluderebbe affatto, anzi.
ma il rasoio di occam è un fondamento del pensiero scientifico, mentre le sue citazioni sono argomento per farci quattro ghignate :-)
 

 [...]mentre le sue citazioni sono argomento per farci quattro ghignate :-)
 
Che poi non sono neanche citazioni. Sono solo cagate che si inventa lui.
 
Citazioni sarebbero:
 
"The one who doesn't fall isn't strong, but it's the one that by 
falling has the strength to get back up." (Jim Morrison)
 
"L’importante non è non cadere, ma non rimanere 'caduti'" (Papa Francesco)
 
 
 

 Che poi non sono neanche citazioni. Sono solo cagate che si inventa lui.
 
autocitazioni. le firma pure.
 

 castrante.
 
Proporsi come innovatore...forse potrei non avere mai avuto le
capacita', ma di certo non ne ho mai avuta l'opportunita'.
 
Ora risponderai che in un posto cosi' non ci si dovrebbe proprio
lavorare, ma non apriamo questo discorso.
 
Scrivo solo per rendere piu' comprensibili le mie risposte.
 
Mi e' capitato di stare in un'azienda che fino a due anni fa
NON USAVA UN SISTEMA DI REVISIONE. Niente bug tracking,
niente test, e una imponente base di codice in C/C++ mantenuta
a colpi di patch per correggere dei problemi solo al momento della
lamentela di qualche cliente.
 
Basito, ho chiesto perche' mai una roba del genere e mi e' stato
autorevolmente risposto che non esisteva un sistema di revisione
che "s'integrasse bene con il workflow aziendale".
 
Poi, con strenua lotta e il supporto di qualche collega siamo
riusciti ad introdurre un belin di SVN con una struttura dei
progetti aberrante per restare comunque compatibili con il
precedente (non)sistema. Si e' accennato anche a Git ma ha
spaventato i capi ancora di piu' della parola "SVN" e non
avremmo spuntato neppure questo risultato migliorativo.
 
Si capira' ora come questi traumi possano avermi indotto a
considerare SVN nonostante ci siano ormai da un bel
po' alternative consolidate e piu' evolute.

On 21/07/2017 15:16, LutherBlissett wrote:
 
[...]> Proporsi come innovatore...forse potrei non avere mai avuto le
 > capacita', ma di certo non ne ho mai avuta l'opportunita'.
 
Non stavo parlando di te, ma dell'OP, il quale arriva in un posto nuovo 
per cambiare le cose, ma poi propone SVN. Sintomo del fatto che sono 
anni che questa persona non lavora seguendo determinati standard de 
facto. Io, se fossi il suo capo, mi preoccuperei.
 
 > Ora risponderai che in un posto cosi' non ci si dovrebbe proprio
 > lavorare, ma non apriamo questo discorso.
 
In un posto dove non si usi un vcs, non ci lavorerei perche` mi farebbe 
capire molto della cultura tecnica dell'azienda.
 
 > Basito, ho chiesto perche' mai una roba del genere e mi e' stato
 > autorevolmente risposto che non esisteva un sistema di revisione
 > che "s'integrasse bene con il workflow aziendale".
 
Che e` una ovviamente una cazzata ed e` anche la scusa che tirano fuori 
i tech lead di certe aziende per giustificare la proprio pigrizia 
tecnologica.
 
 > Si capira' ora come questi traumi possano avermi indotto a
 > considerare SVN nonostante ci siano ormai da un bel
 > po' alternative consolidate e piu' evolute.
 
Quindi tale Alex di Malpensa sei tu?

 Quindi tale Alex di Malpensa sei tu?
 
No, non lo ricordo neppure se postava qui.
Ma da Malpensa ci passaro' presto per un breve viaggio
di piacere, da domani pausa dal lavoro.
 
Saluti a tutti.

 Quei due lì giusto due picioni posso essere :D
 
LOLLLLLLLLLLLLLLL!!!!!!!!!!!!!
 
Infatti abboccano a tutte le briciole buttate per terra ;-)
 
 
 


Minkia mi fate morire per quanto siete stupidi :)
No, non sono tornato: solo necessitavo di qualche link e non usando più client leggo tutto :O

 client leggo tutto :O
 
Interessante. Grazie di avercelo detto.