Consiglio su Project Hosting

[Allanon]

• 

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  

Inoltre io sviluppo su windows seven principalmente con PSPad, cosa mi cambia? Quali tool devo aggiungere?
Insomma datemi qualche dritta, devo evolvermi  

[Allanon]

• 

Innanzitutto grazie per il posto illuminate  

...
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  

[cdimauro]

• 

Google Code supporta SVN e Mercurial.

[TheKaneB]

• 

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.

[Allanon]

• 

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  

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:

[TheKaneB]

• 

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

[Allanon]

• 

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

Ma quali lagne!  
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

[cdimauro]

• 

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...

[cdimauro]

• 

lo credo bene: ma chi usa ancora CVS? :oops:

[cdimauro]

• 

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 ).

[cdimauro]

• 

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.

[Allanon]

• 

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...)

[TheKaneB]

• 

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...

[Z80Fan]

• 

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.

[lumo]

• 

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.