NSA - Non Solo Amiga
SOFTWARE => Linguaggi di programmazione e scripting => Topic aperto da: Allanon - 19 ſettembre 2011, 22:24:40
-
Alcuni utenti mi stanno pressando (in senso simpatico) per utilizzare un repository dove poter mettere il mio progetto GUI per Hollywood e librerie annesse così che possano partecipare allo sviluppo.
Io sono totalmente a digiuno di questa "roba" perchè ho sempre programmato da solo e in locale quindi avrei bisogno di qualche dritta semplice semplice da dove partire.
Esempio: sono andato su google code e mi sono piantato subito quando mi ha chiesto il tipo di server:
- Git
- Mercurial
- Subversion
Per sentito dire credo che il migliore sia SVN (che cmq non ho mai utilizzato) però chiedo lumi a voi altri che magari ci bazzicate tutti i giorni con queste cose :D
Inoltre io sviluppo su windows seven principalmente con PSPad, cosa mi cambia? Quali tool devo aggiungere?
Insomma datemi qualche dritta, devo evolvermi :D
-
Innanzitutto grazie per il posto illuminate :D
...
Io ho utilizzato per anni SVN ed ogni tanto ne sento la mancanza. Se usi TortoiseSVN che si integra alla shell di Windows allora è il paradiso. Sappi che uno dei motivi che mi spinge a non utilizzare Linux è la mancanza di un programma come TortoiseSVN.
Comunque dipende tutto da come vuoi organizzarti. Hai un server tuo o preferisci che il servizio lo offra qualcun altro?
Ho dato un'occhiata al programma che hai indicato e sembra molto bello e completo, stasera mi leggo la guida e lo installo subito :)
Per quanto riguarda il server, no, non ho un server mio (per adesso) ma avevo intenzione di usare qualcosa tipo google code oppure sourceforge
Se vuoi appoggiarti ad un hosting (free con dei limiti), mi trovai benissimo con BitBucket. Hai un repository Mercurial con un sistema di wiki e bugtracking molto carino. C'è anche Tortoise per mercurial (TortoiseHG).
Fino a 48 ore fa non sapevo neanche che esistesse Mercurial, per cui credo che scarterò questa ipotesi per un repo SVN
Comunque se vuoi avere vita facile, vai di SVN con Tortoise e non cambiare, perché tanto poi ti verrà voglia di tornarci (e non sono l'unico che tornerebbe volentieri ad SVN)
Credo proprio che farò così, grazie ancora per i consigli :D
-
Google Code supporta SVN e Mercurial.
-
attenzione che SVN memorizza i suoi metadati all'interno di cartelle nascoste chiamate ".svn", e ce n'è una per ogni cartella sotto versioning. Poi ha una certa difficoltà a tenere traccia degli spostamenti dei file.
Tutto ciò crea problemi in 2 ben precise situazioni:
- Sposto una intera cartella da un posto all'altro senza usare il relativo comando SVN: si fotte il DB di svn e vi conviene rimettere a posto la copia locale o rifare il checkout
- Sposto un singolo file senza usare il relativo comando SVN: il vecchio file viene visto come rimosso, e il nuovo file viene visto come appena importato, con il risultato di perdere lo storico delle modifiche di tale file.
Aggiunta, rimozione e modifica di file e cartelle, invece, vengono gestiti in automatico anche senza usare i relativi comandi, basta ricordarsi di fare Update prima di iniziare a lavorare e Commit quando si è finito.
Altra cosa da tenere presente: SVN non effettua diff tra file binari, ma soltanto su file testuali, quindi non conviene tenere eventuali file zippati, o eseguibili, o file grafici nel progetto, perchè sarebbe del tutto inutile e appesantirebbe il repository senza alcun reale vantaggio.
Il migliore, che non si incasina praticamente mai, che non si impalla nemmeno davanti a migliaia di file modificati, che gestisce i diff binari e tutta una fraccata di altre cose è Perforce, ma è a pagamento e lo usano solo le Software House grosse. Ad esempio un mio amico ed ex collega di Milestone, dove usavamo il discreto AlienBrain (superiore di molto ad SVN), da quando è passato in Codemasters usano Perforce che facilita di molto lo sviluppo in team, tutto un'altro pianeta :-)
Devo investigare un po' Mercurial che, tralasciando le IMHO inutili funzioni distribuite, se usato in modo tradizionale con un server dovrebbe dare caratteristiche superiori rispetto ad SVN.
-
ARGH!!! Mi hai tirato il freno a mano mentre mi dirigevo a tutta velocità verso SVN!!!
:lol:
Allora facciamo così: vi dico cosa devo gestire :D
In pratica si tratta di sorgenti Hollywood, ovvero file di testo semplici.
Saranno una quindicina non di più, uno principale e un po' di "include".
Niente di grosso insomma e con poche dipendenze, cmq niente binari, grafica e roba non testuale.
Resto in stand-by :geek:
-
ah beh, allora vai tranquillo :-D
Per le tue semplici esigenze uno vale l'altro :-)
L'unica cosa da ricordare è che all'atto di spostare file e cartelle devi usare il comando "svn move" oppure usare la GUI di Tortoise (clic destro sulla cartella/file -> TortoiseSVN -> Move).
Le operazioni di cancellazione e aggiunta, invece, Tortoise le rileva in automatico all'atto dell'Update consigliandoti eventuali file non gestiti o scomparsi, che dovrai flaggare a mano nella finestrella in basso... Comunque fai prima a provare e smanettarci che a leggere le mie lagne :D
-
ah beh, allora vai tranquillo :-D
Per le tue semplici esigenze uno vale l'altro :-)
L'unica cosa da ricordare è che all'atto di spostare file e cartelle devi usare il comando "svn move" oppure usare la GUI di Tortoise (clic destro sulla cartella/file -> TortoiseSVN -> Move).
Le operazioni di cancellazione e aggiunta, invece, Tortoise le rileva in automatico all'atto dell'Update consigliandoti eventuali file non gestiti o scomparsi, che dovrai flaggare a mano nella finestrella in basso... Comunque fai prima a provare e smanettarci che a leggere le mie lagne :D
Ma quali lagne! :D
Infatti chiedevo un indicazione di massima, poi con calma mi leggerò la documentazione perché a dire che sono niubbo è veramente riduttivo :lol:
@dsar
Ottimo, vado ancora più tranquillo
-
SVN 1.7 non userà più i .svn per ogni cartella ma solo uno alla radice e sposterà tutto su sqlite.
Finalmente! Ma quanto c'è voluto per arrivarci...
-
lo credo bene: ma chi usa ancora CVS? :oops:
-
Senza dubbio. Comunque progetti molto più grossi sono passati a sistemi di versioning (anche distribuito) completamente diversi; mi suona strano che non abbiano tagliato del tutto i ponti col passato. Sarà che sono un piccolo team e hanno poche risorse da dedicare alla gestione dei repository (una cosa odiosa per un programmatore che vorrebbe pensare soltanto a sviluppare codice :( ).
-
Personalmente per progetti piccoli (con pochi sviluppatori che collaborano e/o pochi commit) preferisco SVN. Altrimenti Mercurial.
E immancabilmente i relativi Tortoise*, di cui sono assuefatto.
-
Vediamo se fra un po' di tempo anch'io riceverò questa "assuefazione" :)
Già che ci siamo: GoogleCode, SourceForge, o altre alternative?
(lo so mi sto approfittando di voi...)
-
Google Code ti consente di tenere il progetto chiuso, mentre Source Forge credo ti costringa ad avere il download ed il repo pubblicamente accessibili... vedi un po' tu.
In generale Google Code mi sembra più semplice da gestire, su SourceForge per fare una release devi smadonnare 3 giorni sul pannello di controllo...
-
Arrivo un po' tardi, io ti avrei consigliato Git; io lo uso con successo sia per il mio hobby kernel, sia per un progetto privato.
Servizi di hosting che supportano git sono il solito SourceForge, oppure GitHub, che dovrebbe dare la possibilità di avere un progetto chiuso.
Però puoi sempre hostare il progetto su una macchina tua, nel caso il progetto fosse privato, come ho fatto io, che ho creato un repository centrale con gitolite.
Il funzionamento è veramente semplice, anche usando un tool a linea di comando.
Dovrebbe gestire abbastanza bene anche i file binari, o per lo meno quei 2-3 file binari che ho gestito son stati memorizzati correttamente.
-
Arrivo un po' tardi, io ti avrei consigliato Git; io lo uso con successo sia per il mio hobby kernel, sia per un progetto privato.
Servizi di hosting che supportano git sono il solito SourceForge, oppure GitHub, che dovrebbe dare la possibilità di avere un progetto chiuso.
Però puoi sempre hostare il progetto su una macchina tua, nel caso il progetto fosse privato, come ho fatto io, che ho creato un repository centrale con gitolite.
Il funzionamento è veramente semplice, anche usando un tool a linea di comando.
Dovrebbe gestire abbastanza bene anche i file binari, o per lo meno quei 2-3 file binari che ho gestito son stati memorizzati correttamente.
Ho usato per un po' git su linux da linea di comando, e mi ci sono trovato abbastanza bene anche se forse è più complesso e meno intuitivo di SVN che avevo usato precedentemente...
però sconsiglio assolutamente git se si lavora su windows, su linux fila dritto, ma su windows è veramente lentissimo poichè usa le librerie di mingw.
-
ma su windows è veramente lentissimo poichè usa le librerie di mingw.
No va lento perché usa le librerie cygwin, non può usare mingw perché Git fa tantissimo uso di syscall POSIX. Motivo per cui è totalmente non-portabile.
Ops era quello che volevo dire anche se ho sbagliato completamente :P
-
ma su windows è veramente lentissimo poichè usa le librerie di mingw.
No va lento perché usa le librerie cygwin, non può usare mingw perché Git fa tantissimo uso di syscall POSIX. Motivo per cui è totalmente non-portabile.
A me Git non piace per vari motivi: è codato una schifezza, non provo simpatia per l'autore che lo ha ideato (Linus Torvalds) e gli unici vantaggi reali rispetto agli altri sono solo il fast merging e il fast branching utili per gestire il progetto caotico e mal organizzato di Linus Torvalds.
Per il resto Git perde in tutto, come le transizioni lente http o in generale via network.
C'è da dire che i version control distribuiti non se li cagava nessuno fino a quando non è venuto Linus Torvalds a dire che "è un'idea figa", tutti quanti a seguire la sua idea e utilizzare Git a manetta, anche per cose che non c'entrano nulla con i codici sorgenti.
:shock: :happy-jumpeveryone: :happy-wavemulticolor:
-
Giusto una precisazione: Mercurial non è scritto interamente in Python. Alcune funzioni, quelle più critiche, sono scritte in C.
-
Ma state tranquilli, è solo un tool, mica vi uccide la famiglia...
http://www.youtube.com/watch?v=4XpnKHJAok8 (http://www.youtube.com/watch?v=4XpnKHJAok8)
Fatevi quattro risate su...
-
E' un tool che funziona male e con un'architettura molto discutibile, ho esposto la mia idea giusto per compensare le tante belle cose che si dicono su Git :-) la gente ne parla troppo bene solo perché è stato ideato da Torvalds
Invece io ne parlo bene perchè lo uso e mi ci trovo bene, e il suo funzionamento mi sembra corretto. Vedi, alla fine non ci sono solo fanatici. ;)
Cmq vorrei sapere se stai solo parlando dell'implementazione (il programma git), o anche della teoria che ci sta dietro. Perchè nel primo caso potrei anche essere d'accordo (nonostante non abbia trovato nessun problema nell'uso pratico), nel secondo invece no, perchè trovo che un sistema distribuito sia migliore di uno centralizzato.
-
Ma state tranquilli, è solo un tool, mica vi uccide la famiglia...
http://www.youtube.com/watch?v=4XpnKHJAok8 (http://www.youtube.com/watch?v=4XpnKHJAok8)
Fatevi quattro risate su...
Ho chiuso subito dopo aver visto che era Torvalds a parlare. Per il resto concordo con dsar.
P.S. Hai mai usato TortoiseSVN/HG? Provali. E poi dimmi se potrai ancora farne a meno. :D
-
Installato Tortoise, adesso faccio qualche esperimento, cmq a me sembra un tool veramente ottimo, l'integrazione nella shell di Windows è impareggiabile :D
-
Ma state tranquilli, è solo un tool, mica vi uccide la famiglia...
http://www.youtube.com/watch?v=4XpnKHJAok8 (http://www.youtube.com/watch?v=4XpnKHJAok8)
Fatevi quattro risate su...
Ho chiuso subito dopo aver visto che era Torvalds a parlare. Per il resto concordo con dsar.
P.S. Hai mai usato TortoiseSVN/HG? Provali. E poi dimmi se potrai ancora farne a meno. :D
Mamma mia, ho resistito 3 minuti e con tutte le stronzate che ha sparato Linus mi è salita un'irrefrenabile furia omicida... Linus è uno dei troll più fastidiosi che ci siano in circolazione...
devo sfogarmi su qualche collega Linuxiano per compensare...:violence-axechase:
-
un version control che ha bisogno di eseguire il garbage collector ogni 10 commit non si è mai sentito e mai potrò accettare un software di questo genere.
Non ho mai eseguito un "garbage collection", e sicuramente ho fatto più di 10 commit. :lol:
Inoltre per i tuoi progetti non va bene Git, i suoi vantaggi si vedono solo su progetti grossi
E non c'è nessun svantaggio nei progetti piccoli. Ci mette 0.9 secondi invece di 0.8 per fare un commit? Decisamente non mi pare un motivo per considerarlo "lento".
Parlo dell'implementazione, Git usa snapshot invece di patch, questo va benone su progetti con una miriade di file, ma non va bene per tutto il resto.
Io so che git memorizza le differenze nel contenuto. Cosa sarebbe uno snapshot?
Non esiste migliore o peggiore. Per un sistema caotico e disordinato come il kernel di Linux o alcuni progetti opensource dove tutti committano senza revisione, il sistema distribuito va bene ed è la soluzione migliore.
Non funziona così, l'accesso al repository non è consentito a tutti. I programmatori chiedono ai mantainer di prelevare le modifiche dal loro repository, oppure inseriscono le patch che vengono inviate via email da altri. Durante le release Linus preleva tutte le modifiche dai mantainer e poi aggiorna il repository principale.
Quindi già qua vediamo una specie di organizzazione.
Nei progetti dove vige un sistema di revisione prima di ogni commit e coordinazione è decisamente meglio un sistema centralizzato, questo è stato uno dei motivi per cui il team di FreeBSD ha rigettato Mercurial a favore di SVN. Tutto questo tralasciando l'aspetto sicurezza dei sistemi distribuiti
Cosa impedisce scusa che non ci sia un sistema di revisione in un sistema distribuito? Git poi ha degli hook che si possono attivare e a cui si possono collegare delle funzioni per diverse operazioni; se proprio non ci si fida dei programmatori, e non si vuole fare un sistema con i mantainer come per Linux, si potrebbero scrivere queste funzioni per eseguire in automatico una build (per vedere se il codice compila), e eseguire la test suite (e eseguire il commit solo se i test passano). Mi rendo conto che questo comporterebbe un bel carico per il server, perciò si può fare in modo che la test suite ritorni un id, codificato in modo che abbini un certo stato del repository (magari lo stesso codice sha1 usato per identificare il commit), e il report della suite. Si creerà poi una funzione che accetta solo i commit che hanno questo codice.
Faccio un esempio di una società che deve fare un videogioco: si creano diversi gruppi, il nostro sarà quello che deve occuparsi del caricamento e della gestione delle risorse. Il nostro gruppo quindi si riunisce, e decidono i vari compiti, come il caricamento delle immagini, dei suoni, dei modelli etc. Inizialmente si comincia il repository con alcuni file di intestazione che definiscono le interfacce dei vari sotto-moduli; a questo punto ogni programmatore crea un branch per sviluppare il sotto-modulo di sua competenza. Quando un modulo è pronto, il relativo programmatore avvisa il capogruppo, che eseguirà un pull dal repo del programmatore, rieseguirà la test suite (perchè è meglio non fidarsi!), e aggiornerà il branch della gestione risorse. Quando tutti i sottomoduli sono completati, verrà eseguito un merge in master.
A me sembra uno scenario abbastanza realistico.
Riguardo la sicurezza, se intendi dire che i programmatori potrebbero portarsi a casa il codice, o che qualcuno possa rubare il portatile dove il programmatore aveva il suo repo, basta fare in modo che si possa lavorare solo dalle workstation dell'azienda. Se poi uno lo vuole prendere proprio e se lo copia con una chiavetta usb, beh, quello si può fare anche con il centralizzato, se uno proprio vuole.
Ovviamente sopra parlo di sistemi distribuiti, quindi puoi anche usare Mercurial al posto di Git; anzi, essendo scritto in Python dovrebbe essere ancora più semplice inserire gli hook no?
P.S. Hai mai usato TortoiseSVN/HG? Provali. E poi dimmi se potrai ancora farne a meno. :D
No, non ho mai usato SVN. Mercurial poi è concettualmente simile a Git, molti comandi hanno anche lo stesso nome, e come ho detto nell'uso pratico non si sente nessun bisogno di maggiore velocità, già adesso è tutto istantaneo.
Edit:
Solo ora ho visto cos'è Tortoise. Sembra un tool molto carino.
Mamma mia, ho resistito 3 minuti e con tutte le stronzate che ha sparato Linus mi è salita un'irrefrenabile furia omicida... Linus è uno dei troll più fastidiosi che ci siano in circolazione...
:doh:
Ma se in 3 minuti non aveva ancora iniziato a dire niente! :D
Le uniche cose che ha detto sono che non è abituato a fare dei discorsi, quindi preferisce che il pubblico gli faccia delle domande, e che si è trovato veramente male con CVS (che anche in questa sede non sembra se ne parli tanto bene).
Cmq, non prendete sempre tutto con serietà su! :lol:
-
Si "gittavano" la home a mo' di backup, soprattutto per i documenti. Siccome viene pubblicizzato come "veloce" tutti a dire "guarda com'è veloce!".
Ma scusa, se usano un tool per uno scopo per cui non è stato costruito, mica è colpa del tool! :lol:
A quel punto gli chiesi: "hai mai usato un version control?"
Questa persona risposte di No, allora come fa a dire che è veloce/migliore se non ha mai utilizzato un version control?
Attento: io non ho mai detto che git "è meglio". E per quanto riguarda la velocità: come ho detto prima, se impiega un secondo per fare un commit, sicuramente non può essere considerato lento, no? ;)
I version control in genere memorizzano i diff tra le varie revisioni dei file, però in un progetto con tanti file questo può avere delle penalità in termini di performance. Git usa uno snapshot, immaginalo come un tarball dell'intero progetto, le modifiche successive sono registrate come "delta" tra il tarball precedente e quello nuovo. Quindi se modifichi 200 file e committi non hai 200 diff per ogni file, ma hai un delta (un unico file simile al diff) tra lo snapshot precedente e quello nuovo con i 200 file modificati. Questo fa tantissimo in progetti grossi con un numero di file enorme, nei progetti medio/piccoli hai delle penalità
Bene, ho capito.
Se questi vengono professati come "vantaggi" del version control distribuito, significa che nessuno ne ha mai usato uno centralizzato, in primis Torvalds. Poi che ci siano problemi nel fare certe cose dipende dal programma, non dal fatto che sia distribuito oppure no.
Beh io ho solo portato un esempio, per dimostrare che si poteva tranquillamente fare anche con un sistema distribuito. Non volevo né tirare fuori dei vantaggi, né denigrare il sistema centralizzato.
Il problema è il concetto estremo di version control distribuito, in cui non vi è il cosiddetto bona fide repository, di conseguenza ogni scambio di informazioni è senza controllo
Beh ovvio, se uno va a pullare in giro da chiunque... :lol: