Newsgroup: it.lavoro.informatica
Titolo: [Forse OT] Sistema di controllo versioni

Ciao,
mi scuso per l'eventuale OT, devo scegliere un sistema di controllo 
versioni (possibilmente gratuito) da usare prevalentemente con sorgenti 
.Net. Le versioni che si integrano nell'IDE sono quasi tutte a 
pagamento, sarebbe sufficiente che venisse integrato nella shell di 
explorer come TortoiseSvn.
La sicurezza relativa all'accessibilitï¿œ esterna ï¿œ demandata ad una vpn, 
ma l'ottimale sarebbe avere una certa granularitï¿œ di privilegi per 
l'accesso da parte di utenti diversi.
Precedentemente, dato che sussistevano vecchi progetti in visual studio 
6, veniva utilizzato visual source safe e si dovrebbe effettuare il 
porting di questi ultimi, manualmente se non esiste un tool specifico.
Ho cercato in rete ed ho notato che svn pare essere preferito a cvs, mi 
chiedevo se vi fossero altre, eventualmente migliori, alternative.
Grazie, ciao. Stefano.
 
 


 >
prova a dare un'occhiata a git.

Dopo dura riflessione, s1gfr1d ha scritto :

Interessante e soprattutto aggiornato, grazie.
Ciao. Stefano.
 
 


Mia personale preferenza: mercurial+add-on per Visual Studio (visto che 
usate una vpn). Controllo di versione di tipo distribuito, senza 
repository centralizzato. Per i privilegi, dipende se vuoi comunque un 
repo centrale o fate le cose con delle directory condivise. Il repo 
centrale con i permessi lo si mette abbastanza rapidamente.
In seconda battuta: git, che è molto simile a mercurial, ma è più trendy 
perché c'è Torvalds dietro...
In terza battuta: Team Foundation Server. Qui le cose si fanno 
complesse, è un prodotto a pagamento ma se hai l'abbonamento a MSDN 
dovresti avere tutto (Windows server, TFS, SQL Server + Sharepoint). E' 
un SCV di tipo centralizzato, tipo SVN, con un po' di cose in più. Però 
con .NET è la morte sua... mi sembra che si possano anche fare le 
compilazioni (build) centralizzate sul server.
 

 Grazie, ciao. Stefano.
 
l'integrazione con l'ide o con la shell grafica è proprio l'ultimo dei criteri per scegliere questi prodotti. 
git e mercurial sono, nell'ordine, di gran lunga preferibili ai due che hai citato. proprio in virtù del fatto che parli di accessibilità esterna questi hanno, fra gli altri, il grosso vantaggio di essere repo distribuiti.
quanto alla migrazione da una rapida ricerca su google ho visto che ci sono abbondanti tools.

 centralizzate sul server.
 
Guarderï¿œ anche questo, grazie.
Per Team Foundation Server ï¿œ molto complicato (anche se da quanto dici 
sarebbe l'ottimale), sto penando per far accettare in azienda l'uso di 
un sistema di controllo versione (attualmente effettuano semplicemente 
i backup con Cobian), se gliene propongo uno a pagamento mi pongono il 
veto immediato :(
Ciao. Stefano.
 
 

 ricerca su google ho visto che ci sono abbondanti tools.
 
Vero, ma devo far accettare in azienda il sistema, attualmente lo 
osteggiano fortemente a favore di sistemi di sincronizzazione di files 
e cartelle condivise, la mentalitï¿œ ï¿œ un po' vecchia :(
L'integrazione con l'ide o la shell aiuterebbe abbastanza.
Approfondirï¿œ la conoscenza di git e mercurial.
Grazie, ciao. Stefano.
 
 


Curiositï¿œ:
Il core business dell'azienda qual'e'?

 cartelle condivise, la mentalitï¿œ ï¿œ un po' vecchia
 
Il change managment questo sconosciuto..........

Scriveva s1gfr1d giovedï¿œ, 19/07/2012:

E' un'azienda manifatturiera i cui prodotti supportano protocolli di 
comunicazioni seriale ed ethernet.
A tale scopo vengono sviluppati internamente applicazioni che fungano 
da proxy tra il prodotto ed un sistema remoto.
Il core business perï¿œ non ï¿œ lo sviluppo di tali applicazioni per quanto 
necessarie per consentire la penetrazione sul mercato dei prodotti.
Ciao, Stefano.
 
 

 [...]
 
 
Git o Mercurial.
 
 
 
Ciao  Manlio

 Grazie, ciao. Stefano.
 
La mia esperienza (nel senso quanti anni ci ho combattuto da amministratore/utente) è 
TFS 7/7 
SVN 8/10 
CVS 2/10+ 
VSS 2/10+ 
git 0/2 
Mercurial 0.1/0.1 
 
i miei voti ad oggi da 1 a 10: 
TFS 2008 8 
TFS 2005 5 
SVN 7 
CVS -100 
VSS -100 
git 8 
Mercurial 8
 
ma metti in conto la poca esperienza con git e soprattutto Mercurial (BTW, a quello che suggerivi tu sopra, da 1 a 10 darei -10000).
 
Ad occhio , se siete su Windows, Mercurial pare più amichevole.
 
Se vuoi provare Git o Mercurial rapidamente o gratuitamente: 
https://bitbucket.org/plans
 (il piano da 5 utenti)
 
Sono quelli che gestiscono: 
http://tortoisehg.bitbucket.org/
.
 
Questo invece ancora non l'ho provato: 
http://visualhg.codeplex.com/
 
 
Se vuoi provare TFS (che però segue un altro modello) gratuitamente: 
http://tfspreview.com/
 
 
-- 
ale
http://ale.riolo.co.uk
 

 e cartelle condivise, la mentalità è un po&#39; vecchia :(
 
capisco il problema, ma ti renderai conto che se queste sono le loro convinzioni lo scoglio non è persuaderli di uno o l'altro strumento ma dell'effettiva utilità di avere un controllo di versione.

Ti ringrazio, approfondirï¿œ seguendo gli utili link che mi hai postato.
Ciao. Stefano.
 
 

 dell'effettiva utilitï¿œ di avere un controllo di versione.
 
Me ne rendo conto, ma parte del gruppo lavorerï¿œ esternamente.
Cercherï¿œ di spiegare loro l'effettiva necessitï¿œ dell'introduzione del 
sistema.
 
 

 A leggere queste cose vengono i brividi. E si chiedono mai chi l'ha modificato quell'algoritmo, e perché? Come verificate che un determinato changeset sia collegato ad un particolare issue? Avete un issue tracking system?
 
Però dipende dalla dimensione dello sviluppo che fanno. Ha già detto
che è solo un'attività di supporto a quella principale dell'azienda.
Non mi stupirei se ciò significa che coinvolge un numero minimo di
persone, ed il software è realizzato in unica versione, per i pochi
computers dell'azienda.
In tal caso va valutato con grande attenzione il beneficio rispetto al
semplice gusto di usare una tecnologia "professionale".

 Ciao, Stefano.
 
Anche se non e' il core business e' strategico visto che serve per 
differenziare i prodotti dalla concorrenza. Non gestendo il cambiamento 
  in maniera piu' efficiente (il tool e' di supporto al processo) il 
rischio e' di ridurre la qualitï¿œ  e quindi l'appettibilitï¿œ dei prodotti 
finali con conseguente perdita di quote di mercato a favore della 
concorrenza.

 semplice gusto di usare una tecnologia &quot;professionale&quot;.
 
a me sembra che, parlando di sorgenti, sui benefici del controllo delle revisioni ci sia ben poco da valutare. questo anche quando lavoro da solo, figuriamoci lavorando in gruppo e oltretutto dislocato in sedi diverse. non so, se preferisci vivere nell'incubo di avere solo e soltanto l'ultima revisione con l'ultimo che arriva che vince...
 

 semplice gusto di usare una tecnologia &quot;professionale&quot;.
 
Stile 10 anni da ora, perché mai quest'algoritmo è stato scritto in questa maniera? A chi gli è venuto in mente di fare una cosa del genere? Com'era prima?
 
Per scrivere software in maniera professionale hai bisogno sempre di strumenti di test automatici e SCM. Nel caso di sviluppatore singolo potrei capire l'indecisione a mettere su un integration server (io lo farei sempre e comunque, ma capisco che una persona molto disciplinata potrebbe farne a meno, ma dubito risparmierebbe qualcosa rispetto a me, anzi), ma su test e SCM no.
 
-- 
ale
http://ale.riolo.co.uk
 

 Per scrivere software in maniera professionale hai bisogno sempre di strumenti di test automatici e SCM. Nel caso di sviluppatore singolo potrei capire l'indecisione a mettere su un integration server (io lo farei sempre e comunque, ma capisco che una persona molto disciplinata potrebbe farne a meno, ma dubito risparmierebbe qualcosa rispetto a me, anzi), ma su test e SCM no.
 
Quoto.

 a me sembra che, parlando di sorgenti, sui benefici del controllo delle revisioni ci sia ben poco da valutare. questo anche quando lavoro da solo, figuriamoci lavorando in gruppo e oltretutto dislocato in sedi diverse. non so, se preferisci vivere nell'incubo di avere solo e soltanto l'ultima revisione con l'ultimo che arriva che vince...
 
La mia esperienza diretta è che un sistema di gestione delle versioni
più semplice ma ben organizzato con regole operative chiare può essere
molto superiore ad uno strumento di versionamento mal digerito.
Poi se pure lavorando da solo hai assoluta necessità del programmino
di versionamento, che dire, fatti tuoi :-)
 
 
 
 

 Per scrivere software in maniera professionale hai bisogno sempre di strumenti di test automatici e SCM. Nel caso di sviluppatore singolo potrei capire l'indecisione a mettere su un integration server (io lo farei sempre e comunque, ma capisco che una persona molto disciplinata potrebbe farne a meno, ma dubito risparmierebbe qualcosa rispetto a me, anzi), ma su test e SCM no.
 
Vedo anche il pericolo che si rinunci alla necessaria disciplina, come
ben dici, scaricando tutto sullo strumento, nell'aspettativa che
risolva da solo i problemi organizzativi. Non metterei un'enfasi
eccessiva sullo strumento piuttosto che sull'utilizzatore.

 explorer come TortoiseSvn.
 
con vs noi usiamo TFS che funziona molto bene oppure metti su git o svn 
i client dovrebbero funzionare anche su win
 
http://code.google.com/p/tortoisegit/
 
 
http://tortoisesvn.tigris.org/
 
 
ps
pensa che noi abbiamo ancora dei sorgenti sotto cvs... O_o
 
ciao
 
 
 
 
-- 
http://www.evilripper.net
 
http://www.flickr.com/photos/evilripper/
 
 
 

 di versionamento, che dire, fatti tuoi :-)
 
per quello che costa (zero) e per l'overhead che comporta sullo sviluppo (assolutamente nullo) trovo sia da fessi lavorare senza il paracadute di un sistema di versionamento. però ho il sospetto che non conosci ne git ne mercurial, per cui fintanto non ti sei fatto un idea su almeno uno di questi due non si arriva a nulla.  

 Per scrivere software in maniera professionale hai bisogno sempre di strumenti di test automatici e SCM. Nel caso di sviluppatore singolo potrei capire l'indecisione a mettere su un integration server (io lo farei sempre e comunque, ma capisco che una persona molto disciplinata potrebbe farne a meno, ma dubito risparmierebbe qualcosa rispetto a me, anzi), ma su test e SCM no.
 
+1
 
Andrebbe incorniciato, stampato in formato poster e attaccato in ogni
parete dell'azienda...
 
Esempio contrario:
 
Azienducola della Vallesina, 20 anni sulla breccia, un pugno di
programmatori che sfornano gestionali e interfacce per dispositivi
custom (casse, ciaffi rfid, ...). Il software � scritto in un linguaggio
obsoleto da trentanni, che in Italia lo parla giusto la famiglia Flinstone.
Hanno un fottio di clienti e non sanno a chi dare il resto. La crisi?
Non sanno neanche dove sta di casa...
 
I sorgenti sono salvati in una selva di cartelle di un disco condiviso
di un vecchio server Windows. Cartelle annidate
"versione_pre_1_luna_nuova", "versione_forse_funzionante_per_cliente_X",
"versione_funzionante_con_mercurio_in_opposizione_a_giove" ... dove
chiunque in qualsiasi momento pu� scrivere.
 
Arriva un nuovo schiavetto, anni di esperienza con gestionali pi�
complessi, certificazioni, laurea coi fiocchi, contratto 
co.co.pro
 da
due soldi. Vede questo bordello. Propone l'utilizzo di un VCS.
Risposta: "Cosa? Che cos'�? Non ci serve..." (diciamo che la risposta �
stata anche meno gentile).
 
Io aspetto il giorno ... perch� se c'� una qualche giustizia a questo
mondo questo giorno arriver� .. che questa azienda faccia il botto fino
a Betelgeuse...
 
M.

 stata anche meno gentile).
 
Chiamasi miopia imprenditoriale. Almeno prima di dire non serve cambiare 
metodo di gestione per partito preso cercare di capire  e valutare quali 
sono vantaggi e svantaggi di un eventuale cambiamento sarebbe sintomo di 
intelligenza.


Sembra la discussione che stiamo portando avanti noi in azienda: io ho 
già attivato mercurial via https su un server, più MS TFS (visto che 
l'abbiamo pagato...). Il responsabile di reparto non ne vuole sapere, 
perché ritiene più produttivo fare uno zip due volte al giorno con i 
sorgenti dei progetti.
"Con Total Commander clicchi sulla dir, fai zip, lo copi sul server, e 
se qualcosa va male scompatti lo zip più recente e ricominci. Con 
stica$$i che mi vuoi far usare, perdi più tempo a dare comandi che a 
scrivere codice." (*)(**)
 
(*) Questa è la versione ridotta per i minori di 18 anni. Quella per i 
più scafati è durata 1+ ore, di cui il 99% a base di epiteti vari.
(**) Questo tizio non mette 1 commento che è uno. Anzi, se ne trova li 
cancella, anche i miei!
 
Io comunque vado avanti lo stesso: i progetti li metto in mercurial (o 
TFS, nel caso di .NET).

 sorgenti dei progetti.
 
Ho omesso una parte del racconto.
 
Questo che tu descrivi sarebbe stato, nell' azienda da me citata, già
grasso che cola.
 
Il neo-schiavetto, dopo il rifiuto del VCS, ha proposto l'utilizzo di
dispositivi esterni (anche usb) per l'archiviazione dei codici sorgente
in copie di backup compresse e organizzate per data. Ogni programmatore
avrebbe avuto l'onere di archiviare la propria parte di competenza
(anche se sovrapposta a quella di altri).
 
"Tempo sprecato e poco sicuro per la policy dell'azienda.. gli archivi
potrebbero essere trafugati" è stata la risposta...
 
Se avessi tempo ci scriverei un libro. Comico.
 
M.

 Se avessi tempo ci scriverei un libro. Comico.
 
guarda io non credo che un programmatore debba avere la vocazione del missionario. 
 
se, come nel caso di quasimodo, uno ha *almeno* la possibilità di ritagliarsi uno spazio all'interno del quale fare "come gli pare" (che poi non è altro che seguire le regole consolidate di buonsenso) allora passi; ma se uno deve essere costretto a disimparare onde adeguarsi ad un modo di lavorare in cui ha tutto da perdere (perché se in tutto quel gioco di copie fatte a mano si perde un solo byte indovina chi ha sbagliato?) e per di più per un contratto a progetto pagato due lire, mi domando che ci sta a fare? 

 allora passi; ma se uno deve essere costretto a disimparare onde adeguarsi ad un modo di lavorare in cui ha tutto da perdere (perch� se in tutto quel gioco di copie fatte a mano si perde un solo byte indovina chi ha sbagliato?) e per di pi� per un contratto a progetto pagato due lire, mi domando che ci sta a fare? 
 
Infatti li ha mandati affanculo :-)
(seguendo un po' il motto di Marcoxxx)
 
M.
 
 

 cancella, anche i miei!
 
Qui dipende. Se il codice è leggibile, è meglio non avere commenti ridondanti. Poi se il tipo ti cancella commenti stile "ma chi è quell'idiota che ha usato bubblesort per ordinare mezzo milione di elementi sul client?" è un altro discorso.
 
BTW, mai letto nulla di simile:
 
// incredibile argoritmico per ordinare i clienti
// senza usare ORTER BY del database perchè
// ho letto su una rivista che è lento
public OrdinaMezzoMilioneDiClienti()
{
	// funzione per prendere tutti i clienti
	// dal database senza usare ORDER BY
	var clienti = PrendiTuttiClientiDalDB();
	// while all'incontrario
	do
	{
		// questa è la funzione geniale: dentro OrdinaRandom
		// vengono aperti 2 treats per ogni processore
		// che prendono tutti i clienti dal database
		// senza usare ORTER BY, come suggerito dalla rivista
		// Il primo treat che ritorna, ammazza tutti gli altri
		// e ritorna in maniera superveloce
		// un array compresso con zip/rar/bzip/7z/tar/jpeg100%
		// che contiene tutti i clienti ordinati
		// in maniera del tutto random
		// non serve ordinarli ora perché poi c'è l'altra funzione
		// che viene dopo.
		// AGGIORNAMENTO: ora che abbiamo comprato i multicore,
		// 2 thread per multicore!
		var clientiOrdinati = OrdinaRandom(clienti);
		// ora poi c'è l'altra funzione
		// che viene dopo.
		// questa è la funzione ancora più geniale: dentro ControllaOrdine
		// vengono aperti 2 treats per ogni processore
		// ogni treat decomprime l'array, applicando in ordine:
		// jpeg100%, tar, 7z, bzip, rar e zip
		// una volta che abbiamo di nuovo l'array con tutti i dati
		// leggibili, ogni treat chiama OrdinaRandom, vedi sopra
		// per la descrizione di quella funzione geniale,
		// ed alla fine lo confronta con un array hartcored,
		// cioé scritto a mano, dove c'è l'elenco alfabetico
		// di tutto il mezzo milione di clienti, attenzione
		// a non modificarlo senza il mio permesso che ci ho messo 
		// 9 mesi a ordinarlo riga per riga su notepad, non
		// ho potuto fare l'ordinamento su Excel perché
		// è bacato, mi mette la mutina prima della I,
		// e se anche lo modificate, ho il backup nel
		// computerre di casa mia, per cui vi scancello in ogni caso
		// tutte le modifiche. Allora, dicevamo, abbiamo
		// un array hartcored, lo confrontiamo con l'array
		// ordinato random dalla funzione geniale di cui sopra
		// ho già parlato abbondantemente, e se sono uguali,
		// tutto è andato a posto, ritorniamo true,
		// altrimenti aspettiamo un altro treat, e via di questo passo
		// se nessuno dei treat ritorna un array uguaglio
		// ControllaOrdine ritorna false, e questo permette
		// al do while, che è un while all'incontrario,
		// di continuare a controllare altri ordinamenti random,
		// usando tanti treat, finché non ci azzecchiamo quello giusto.
		// AGGIORNAMENTO: ora che abbiamo comprato i multicore,
		// 2 thread per multicore!
		// AGGIORNAMENTO: ho letto su un'altra rivista
		// che potremmo usare reagenti in altri computerre,
		// per parallassizzare ancora di più questo argoritmico,
		// ma ancora non ho capito bene come fare,
		// ci dedicherò le ferie anche quest'anno,
		// la rivista diceva che Guggule usa questo argoritmico!
		bool sonoOrdinati = ControllaOrdine(clientiOrdinati);
	} while (!sonoOrdinati);
 
	// se vuoi sapere il nome della rivista,
	// chiedilo a me, che tanto non te lo dico.
	// Bisogna studiare da soli, altro che trovare il piatto pronto!
}
 
-- 
ale
http://ale.riolo.co.uk
 

 Qui dipende. Se il codice � leggibile, � meglio non avere commenti ridondanti. Poi se il tipo ti cancella commenti stile "ma chi � quell'idiota che ha usato bubblesort per ordinare mezzo milione di elementi sul client?" � un altro discorso.
 
Il "vizietto" di cancellare i commenti altrui succedeva anche
nell'azienda di cui ho parlato.
 
Il motivo era molto semplice: nascondere, eliminare qualsiasi
riferimento del codice scritto al suo autore, in modo di prendersi
meriti non propri.
 
Nel caso specifico, il dipendente a tempo indeterminato, rozzo e
ignorante come un orso grizzly che soffre di emorroidi, non voleva
sfigurare di fronte all'ultimo arrivato, ma anzi prendersi i meriti nel
caso in cui il software scritto da quest'ultimo funzionasse meglio del
suo (ecco, poi, un'altro dei motivi per non usare il VCS...).
 
M.


Ciao,
per SVN ti segnalo questo add-on gratuito per Visual Studio, AnkhSVN.
Lo trovi su 
http://ankhsvn.open.collab.net/
 
Io lo uso da anni e in generale non mi ha mai dato problemi.
Tieni conto che funziona solo sulle versioni non-express di visual studio.
Se devi implementare un server effettivo ho usato anche VisualSVN Server 
http://www.visualsvn.com/server/
 
Attenzione che il server e' free, l'eventuale addon pefr visual studio 
e' a pagamento.
Io l'ho usato senza problemi in combinazione sia con AnkhSVN sia con 
TortoiseSVN.
 
Roberto

 M.
 


Io sviluppo codice da solo, e ti posso dire che un software di controllo 
versione "professionale" è **indispendabile** (per la cronaca uso 
Mercurial).
 
 
Ciao  Manlio

 versione "professionale" è **indispendabile**
 
Quoto, quoto, quoto.
Soprattutto quando il codice raggiunge dimensioni ragguardevoli ed � 
finemente customizzato al variare dei numerosi dispositivi target.
Alla fine non riesci pi� a stare a galla l� dentro. Io mi perdo.
 
 
 
Ciao! Buona serata.
---
none^none

 fine non riesci più a stare a galla lì dentro. Io mi perdo.
 
ma anche se il progetto è piccolo, con git o mercurial creare un 
repository per un progetto è veramente una operazione che non costa 
nulla. forse qualcuno pensa che si debba mettere su chissà cosa. a me il 
solo fatto di modificare un sorgente sovrascrivendo una versione 
funzionante la trovo una cosa stupida, o meglio un modo per buttare nel 
cesso il lavoro. 

 cancella, anche i miei!
 
Invece tu pensi che programmatori IN-disciplinati, quando catalogano
una versione con lo strumento apposito, riempiono scrupolosamente i
campi di descrizione? Sei abbastanza novello, allora :-)
Lo strumento è utile, ma conta molto più la convinzione nel dover fare
le cose in un certo modo e la precisione nell'applicarle. Non il
contrario.
 
 

 contrario.
 
queste l'ho già detto sono affermazioni vacue. è come dire: per piantare un chiodo conta più la convinzione di dover picchiar forte e la precisione di colpire la testa e non le dita; benissimo, ma lo vogliamo dire che senza il martello restano bei discorsi e il chiodo non lo pianti?
 
 
 
 

 campi di descrizione?
 
Siccome sono io che poi faccio i merge nei branch/repo di staging e di tag, se trovo uno sviluppatore che mi ha fatto il commit di un changeset senza commenti, issue number, e tutti i riferimenti necessari, lo martello come un chiodo.
 
Anzi, per dirla tutta, dato che il backend di TFS è Sql Server, mi sono scritto le query per controllare in automatico che tutti siano ligi un paio di volte a settimana (ogni tanto c'è qualche problema con i nuovi, soprattutto offshore).
 
Dopo una martellata, con in CC tutta la linea di comando fino al CdA, imparano tutti. Come sviluppatori questo fa parte del nostro lavoro, siamo all'ABC, fare un commit senza commenti è un comportamento inaccettabile, ed è mancanza di rispetto verso i colleghi, gli stakeholder e soprattutto i clienti.
 
Non parliamo di sviluppare senza vcs poi ...
 
-- 
ale
http://ale.riolo.co.uk
 
 

 queste l'ho già detto sono affermazioni vacue. è come dire: per piantare un chiodo conta più la convinzione di dover picchiar forte e la precisione di colpire la testa e non le dita; benissimo, ma lo vogliamo dire che senza il martello restano bei discorsi e il chiodo non lo pianti?
 
 
Ok, è tutto vacuo ed opinabile: scrivere i commenti o descrizioni,
usare una id personale, costruire i branch come si deve.... Gli dai
l'interfaccia del versionatore ed è tutto fatto, c'hai la storia, e
tanto basta.
Vista così semplice la cosa è assolutamente convincente, non c'è
dubbio :-)

 cesso il lavoro.
Se modifichi i sorgenti, rischi grosso di perdere codice utile. E i 
sorgenti con codice revisionato pi� volte sono ben lontani dalla decenza.
 
Se vai a mano e salvi uno dopo l'altro i rilasci che di tanto in tanto 
consegni al cliente, tanto vale la gestione semiautomatica con i tool di 
cui sopra. Poi si possono applicare anche a cose pi� ampie oltre al 
codice strettamente detto (improvviso: versionificare un db a seconda 
del livello acquistato dal cliente, a seconda delle edizioni, ecc. ).
 
Purtroppo (il caso � capitato anche a me) in Italia la mentalit� miope 
(e meschina) ci impedisce di veder chiaro anche nelle faccende pratiche.
 
 
 
 
Ciao! Sempre ottimissima giornata.
---
none^none
 


Convinzione? Se l'azienda per cui lavori  stabilisce che bisogna seguire 
un certo processo per raggiungere una certa qualit� e tu non  lo segui 
rischi che  ti licenzino per giusta causa e  a ragione.
Che lo strumento sia di supporto al processo questo e' naturale. Ma 
tieni presente che senza lo strumento adeguato il processo non lo 
implementi.

 tanto basta.
 
ma no che non basta. 
io sto dicendo che un sistema di gestione versioni è *indispensabile*, non che sia sufficiente. 
a proposito, ancora non hai risposto alla precedente domanda per cui reitero:  mi fai un esempio pratico di "un sistema di gestione delle versioni più semplice" di un vcs? o di "ben organizzato" che faccia a meno di un vcs? 

 di versionamento, che dire, fatti tuoi :-)
 
Un "programmino" di gestione delle versioni concorrenti � utile anche 
se si sviluppa da soli.
La possibilit� di aprire dei branch, ad esempio, � *molto* utile, cos� 
come "taggare" tutti i sorgenti associati ad una release. In generale, 
che esista un sistema che consenta di non "perdere" niente, tra una 
modifica e l'altra al codice, � utile in qualunque contesto. 
 



On 2012-07-19 11:26:47 +0000, ispas said:




Non tutte le aziende sono l'IBM. Bisogna stare molto attenti a non


sparare alla mosca col cannone.




I sistemi di versionamento sono tutto fuorch� cannoni per sparare alle mosche.
�


La differenza tra chi usa un sistema di versionamento e chi non lo usa, � che i primi lavorano in maniera professionale, i secondi no. Se si tiene al proprio business, si deve essere professionali anche se si � un'azienda di 3 persone.




Vedo anche il pericolo che si rinunci alla necessaria disciplina, come


ben dici, scaricando tutto sullo strumento, nell'aspettativa che


risolva da solo i problemi organizzativi. Non metterei un'enfasi


eccessiva sullo strumento piuttosto che sull'utilizzatore.




Per la serie: non enfatizziamo troppo gli sportelli, quanto la disciplina in curva del guidatore :-)


Lo scopo di un sistema di versionamento non � di risolvere "problemi organizzativi".
�


Non � che un vcs � un'alternativa automatica, comoda, ad un lavoro manuale certosino. Qualunque rimpiazzo manuale di un vcs � uno sforzo inutile, inefficiente, poco sicuro e poco professionale.







 generica  :-) (visto fare, sai per semplicit�.... )
 
Anch'io l'ho visto fare. Quindi ho preso l'amministratore per un 
orecchio, gli ho fatto creare un account per ogni sviluppatore, e ho 
cazziato gli sviluppatori, dicendogli di usare ognuno il proprio 
account.
Ma queste sono proprio le basi.
 

 Non parliamo di sviluppare senza vcs poi ...
 
Quoto al 100%.
 

 cesso il lavoro.
 
Assolutamente concorde.
Nei primi anni della mia carriera mi sono trovato spesso a scrivere 
sistemi abbastanza complessi, su cui lavoravo in prevalenza da solo. 
Non conoscevo l'esistenza dei VCS, ma sentivo la necessit� di tracciare 
le versioni per sicurezza. Quando qualcuno mi ha introdotto all'uso di 
questi sistemi, mi si � aperta la mente.
Era come aver trovato il pezzo che mi mancava.
 

 condivise, la mentalitï¿œ ï¿œ un po' vecchia :(
 
vi obbligano anche ad usare cellulari etacs?
 
perche' il concetto e' lo stesso
 
-- 
We are the music makers,
And we are the dreamers of dreams
 
 

 modifica e l'altra al codice, è utile in qualunque contesto.
 
Secondo me intende dire che se alcuni componenti del team sono 
insofferenti al sistema di versioning (inteso come software con le sue 
regole), è meglio lasciare perdere.
Rischi che, mentre alcuni usano il sistema di versioning, altri facciano 
modifiche all'infuori del ciclo, perché "...a me quelle pugnette non 
interessano, ho altro da fare...".
Cose già viste al tempo di CVS, con modifiche che "vanno e vengono" 
senza motivo apparente, salvo poi scoprire che c'è appunto qualcuno che 
non usava CVS!
 


Non abbiamo cellulari. Solo centralino rigorosamente non-passante!
 

 modifiche all&#39;infuori del ciclo
 
Questo non è possibile perché non accettabile. O tutti usano il vcs, o non lo usa nessuno. Non esistono vie di mezzo.