Si, infatti, altrimenti si perde il filo.
Ad ogni modo ho spostato questa discussione in testa, così da evidenziarla.
Inoltre, sul repository su sourceforge, oltre a creare le tre cartelle di cui avevo parlato nella discussione, ho aggiunto una branch, identificata dal nome "1.0", che conterrà i sorgenti dello sviluppo per le tutte le versioni dalla 1.0.0 fino alla 1.0.999 e via dicendo. Quando si deciderà di passare ad una release superiore, ad esempio la 1.1.0, si creerà un'altra branch targata "1.1", e così via.
In parole povere, l'idea è questa:
1) la cartella branches, conterrà i sorgenti dello sviluppo continuo di un range di sotto versioni
2) una volta deciso che si è raggiunto l'ok dei sorgenti, si decide di crearne una release definitiva pubblicabile (es. 1.0.0, 1.0.1 e così via). Lo stesso vale sulle versioni successive (es. 1.1.0, 1.1.1, ...) (es. 2.0.0, 2.0.1, ...).
3) la release definitiva viene congelata, facendo una copia nella cartella trunk, e soto un'ulteriore cartella nominata come la versione (es. trunk/1.0.0).
4) per utilizzare una release specifica, quindi facendo un download per i nostri programmi, basta accedere al repository, posizionandosi nella cartella trunk/<release> che ci serve. Questo permette a chiunque di usare la release desiderata, cosa auspicabile se si dispone di versioni di gambas diverse, che potrebbero portare ad alcune incompatibilità.
5) lo sviluppo comunque continua sempre, tocca solo stare attenti su quale branch andiamo ad operare.
6) per il momento la cartella trunk non verrà usata.
7) nella rispettiva cartella branch andremo a creare un'ulteriore cartella, che identificherà la singola libreria. In questo modo, chi opera su quella libreria non và ad interferire sulle altre. Oltre a questo, la logica ci permette di separare in gruppi le varie librerie in base alle loro funzionalità (es. clib.network, clib.xml, clib.database, clib.desktop, ...)
Se vai sul repository, vedrai che per ogni cartella viene riportato il comando utile per crearsi la propria copia locale:
svn checkout --username=<utente> svn+ssh://<utente>@svn.code.sf.net/p/the-big-clib/code-0/ the-big-clib-code-0
Tanto per spiegare cosa significa la riga di comando:
svn: il comando per gestire subversion
checkout: il parametro che indorma svn di fare lo scaricamento dei sorgenti in una cartella locale (nel proprio pc)
--username: identifica l'utente che accede al repository. In questo caso è necessario solo perchè come amministratore, o utente registrato alla libreria clib, ho i diritti di lettura/scrittura.
protocollo://utente@url: accede alla cartella virtuale del repository (così come la vedi su sf.net. E' sottinteso che il comando è impostato per scaricare completamente tutta la struttura della libreria clib. Nel caso non sia necessario, si può delimitare il download solo a una certa branch/versione, magari perchè si vuole lavorare esclusivamente su quella. La cosa non è auspicabile, in quanto è possibile che il nostro codice vada ad agganciarsi ad altre funzioni contenute in altre librerie.
ultimo parametro: in realtà questo è facoltativo, e indica a svn di creare la copia locale nella cartella indicata (the-big-clib-code-0), che verrà creata automaticamente sotto la directory cui si correntemente posizionati (es. se si è in /home/utente, la nuova cartella verrà creata sotto questa: /home/utente/the-big-clib-code-0).
Una volta scaricata la nostra copia locale, possiamo aprire il nostro gambas e andare ad operare sul codice. Terminate le modifiche, o anche fatte solo in parte, si può decidere di aggiornare il repository con le nostre modifiche. In pratica, da ora in poi, i comandi che verranno utilizzati sono pochissimi:
verifica le differenze tra la nostra copia e il repository e, nel caso, aggiorna la nostra copia con le nuove modifiche effettuate da altri programmatori.
visualizza lo stato dei file, se aggiunti, modificati, o altro
svn commit -m "sommario delle modifiche"
Per chi, invece, vorrà scaricarsi una delle versioni pubblicate e congelate, potrà accedere direttamente nella cartella trunk/<release>, scaricandosi i sorgenti (che nessuno poi toccherà in quanto congelati).
Un'altra possibilità è quella di fornire le versioni in pacchetti, anche solo contenuti in file compressi. In questo caso è necessario che un amministratore costruisca il pacchetto e lo scarichi sempre su sf.net (ci sono apposite procedure per farlo, anche piuttosto semplici). Questo ci permette di pubblicare direttamente i sorgenti in un unico file (può anche essere un rpm, ad esempio). Questo file verrà visualizzato nel sommario di sourceforge, e chiunque potrà scaricarlo direttamente dal sito con un semplice click.
Spero che quello che ho scritto sia esauriente, ad ogni modo se qualcuno ha dei dubbi o quesiti da porgere, sono qui, nel limite delle mie possibilità e conoscenze.