LESS the dynamic stylesheet language

LESS è un semplicissimo linguaggio creato da Alexis Sellier per rendere dinamici i CSS grazie all’implementazione di variabili, funzioni, espressioni e annidamenti. Facilita di molto lo sviluppo e la manutenzione di CSS molto articolati. Per utilizzarlo basta includere nelle pagine web oltre al file style.less(potete chiamarlo come vi pare) che conterrà il sorgente scritto da voi in less anche il file javascript che lo trasformerà in un file CSS e lo integrerà nella pagina.

<link rel="stylesheet/less" type="text/css" href="style.less">
<script src="less.min.js"></script>

Non preoccupatevi di dover imparare molte cose per poterlo utilizzare, un file CSS viene già compilato correttamente da LESS e vi basterà apportargli qualche modifica per sfruttarne le potenzialità.

Ora un esempio molto veloce e non esaustivo di quello che LESS può fare:

@arancio: #ebac20;
@rosso:   #d84227;
@larghezza:  20px;
@url-base:     "http://dominio.it/images/";

.rounded-corners (@radius: 5px) { 
   border-radius: @radius; 
   -webkit-border-radius: @radius; 
   -moz-border-radius: @radius; 
}

.box{
    border: 2px solid @rosso;
    background: url("@{url-base}logo.png") 0 0 no-repeat @arancio;
    .rounded-corners(20px);
    p { width: @larghezza * 2; }
}

Questo codice LESS produrrà il seguente codice CSS:

.box {
    border: 2px solid #d84227;
    background: url("http://dominio.it/images/logo.png") 0 0 no-repeat #ebac20;
    border-radius: 20px;
    -webkit-border-radius: 20px;
    -moz-border-radius: 20px;
}

.box p {
    width: 40px;
} 

Come potete vedere se per esempio utilizzate il colore arancio 50 volte nei vostri CSS ma un giorno vi svegliate e volete cambiare leggermente tonalità vi basterà cambiare il valore alla variabile @arancio senza dover utilizzare find and replace.

.rounded-corners (@radius: 5px) invece è un esempio di funzione che accetta come paramentro un numero di px (di default saranno 5) e semplifica il codice invece di dover ripetere tutte le volte le tre direttive per i bordi arrotondati per ogni browser.

Per evitare di dover scrivere per esteso tutti i percorsi CSS è possibile annidare i vari marcatori e LESS ve li scriverà automaticamente per esteso come nell’esempio p è descritto all’interno di .box.

Queste sono le principali caratteristiche, ma LESS ne mette a disposizione molte altre come gli @import, le operazioni, alcune funzione di javascript, funzioni sui colori, namespace e scope. Per scoprirle vi rimando alla pagina ufficiale da cui potete anche scaricare l’unico file che vi serve per cominciare ovvero less.min.js.

Usi Internet Explorer? Beccati la pubblicità. Usi IE6? pubblicità doppia

ORMAI è da qualche tempo che ho rinunciato completamente alla pubblicità sul mio sito, oltre al fatto che ci guadagnavo poco, l’ho fatto principalmente per questioni di pulizia del layout e per infastidire di meno i visitatori potenziali lettori (la pubblicità infastidisce è ovvio). Ma visto che ogni volta che sviluppo un sito devo passare parte del mio tempo a renderlo, non dico uguale a come viene visualizzato negli altri browser, ma almeno utilizzabile da Internet Explorer, e anche questo mi infastidisce parecchio, mi sembra quasi doveroso e moralmente giusto, per la legge del contrappasso, infastidire chi usa Internet Explorer. Continue reading

Tieni traccia e confronta nel tempo l’Alexa Rank di vari domini

PIU’ che altro per curiosità personale (visto che conta nulla) avevo intenzione di tenere traccia dell’alexa rank del mio sito, poi una cosa tira l’altra e quindi ho creato una mini applicazione per confrontare tramite dei grafici l’andamento dell’alexa rank fra vari domini se vi interessa per curiosità potete provarlo a questa pagina: alexa.gianlucacrema.com

Per ora ci sono circa 300 domini registrati e ogni giorno si aggiornano i dati dell’alexa rank, potete confrontare fino ad n domini contemporaneamente, non ho messo limiti (finche non va in crash la pagina). Potete aggiungere molto facilmente qualunque dominio vi pare e da quel giorno verra registrato l’alexa rank.

Può essere interessante vedere come nel tempo si modifica l’alexa rank. Tempo permettendo faro dei mini tutorial sugli script jQuery che ho usato per creare i grafici, l’autocomplete e sulla parte in php che grazie ai cron jobs ogni giorno alle 05.12 salva nel database i dati sull’alexa rank di tutti i domini registrati. Magari datemi qualche feedback qua nei commenti e se vi interessano i dati chiedetemi pure che ve li mando.

Compressione gzip senza il modulo apache mod_gzip

LA maggior parte dei servizi di shared hosting offrono la compressione gzip di default, come per esempio dreamhost dove al massimo è da disattivare non da attivare. Invece con lunarpages (che per la cronaca anche se non centra nulla ieri un attacco DoS lo ha fatto andare interamente down per un oretta) con il servizio base di shared hosting non consente di attivare il modulo di apache mod_gzip.

C’è un modo forse un po macchinoso ma comunque funzionale per ovviare a questo. Essendo che utilizzano suPHP è possibile tra le altre cose personalizzare il file di configuarazione php.ini per ogni cartella sul server. Ciò consente di abilitare zlib.output_compression ovvero l’estensione di PHP che a runtime “on-th-fly” al volo come recita il manule di php comprime l’html risultante da una pagina php prima di inviarlo ai browser. Per attivarlo quindi basta creare un file php.ini e scriverci:

zlib.output_compression = On
zlib.output_compression_level = 6

Per poter comprimere tutti i documenti, dai fogli di stile ai javascript, e non solo gli script php basta far processare a PHP tutti i file che vogliamo comprimere, pertanto andremo a scrivere nel file .htaccess

AddHandler application/x-httpd-php5 .css .html .js
suPHP_ConfigPath /home/username/public_html/

La direttiva AddHandler serve a far processare a PHP tutti i file con estensione .css, .html e .js potete aggiungere ogni estensione che vi pare, la seconda riga invece serve per specificare il percorso del file di configurazione php.ini, al posto di username va ovviamente il vostro username e dopo public_html potete specificare qualsiasi percorso dove sia presente un file php.ini.

Ora tutti i file prima di essere visualizzati verranno compressi, questo però può comportare dei grossi problemi, l’header di risposta per esempio di un foglio di stile potrebbe non essere più lo stesso, pertanto bisogna ristabilire gli header giusti. Un modo molto semplice è includere prima di ogni file questo script.

<?php
$path = pathinfo($_SERVER['SCRIPT_NAME']);
 if ($path['extension'] == 'css')  {
 header('Content-type: text/css');
}
if ($path['extension'] == 'js')  {
 header('Content-type: application/x-javascript');
}
?>

per farlo bisogna salvare questo script in un file denominato per esempio pre.php e aggiungere al file php.ini questa riga:

auto_prepend_file = "/home/username/public_html/pre.php"

Così ora i file con estensione .js, .css e .html prima verranno processati da php quindi compressi poi gli sarà restituito il giusto header e infine inviati al browser. Attenzione che se avete dell’xml all’interno di questi file tra i tag <?xml ... ?> verrà processato da php, per ovviare a questo basta aggiungere a php.ini il comando:

short_open_tag = 0

questo disabilita gli short tag <? ... ?> per php quindi come è giusto che sia tutto il codice php va messo assolutamente all’interno dei tag <?php ... ?>

Confronto tra Git, Mercurial e Bazaar

PERCHE’ limitare il confronto tra questi tre e non includere, per esempio, subversion (di cui ho scritto nell’Introduzione al controllo di versione)? Oltre che essere rilasciati tutti e tre sotto licenza GNU sono accomunati dall’appartenenza ad una tipologia particolare di software di controllo di versione. Git, Bazaar (bzr) e Mercurial (hg) sono DVCS (distribuited version control system) ovvero sistemi di controllo di versione nei quali ogni working copy locale contiene l’intera storia di tutte le modifiche apportate in tutte le revisioni precedenti. Questo consente di “navigare” tra le varie modifiche e revisioni senza dover interrogare il repository centrale che risiede solitamente su server remoti aumentando notevolmente la flessibilità.

Con DVCS in realtà viene a mancare l’idea stretta di repository centrale, ogni working copy è un repository, ovvio che per collaborazione tra più sviluppatori e per motivi di backup è sempre necessario un server remoto. Per vedere tutti i vantaggi di questa classe di VCS vi consiglio di visitare la relativa pagina di Wikipedia versione inglese.

Ma tra questi tre DVCS quale scegliere? Google nell’estate del 2008 ha già fatto e pubblicato un attenta analisi di confronto tra Mercurial e Git, con annessa discussione, per decidere quale software utilizzare assieme a subversion nel servizio code.google.com. Per la cronaca hanno scelto Mercurial avanzando una maggiore efficienza nell’uso del protocollo HTTP e di una minore difficoltà di approccio. Bazaar nato nel dicembre dell’anno precedente forse era ancora troppo acerbo per essere preso in considerazione ma ora è il terzo più popolare e sicuramente all’altezza degli altri due.

Lo scopo di questo post non è dire, questo è migliore di quell’altro, cosa che ritengo impossibile visto che parliamo di software supportati da grandi progetti e sicuramente equiparabili ma cercare di evidenziarne le differenze per aiutare la scelta a seconda delle diverse necessità.

  • Git è sicuramente più ostico per chi si avvicina per la prima volta a questo tipo di programmi, Mercurial e Bazaar sono sicuramente più semplici ad un primo approccio. Sopratutto per chi già usa svn si troverà sicuramente bene con Mercurial.
  • I benchmarck dicono che Git è più performante rispetto agli altri due nelle operazioni di commit, diff, e iniziallizzazione, Mercurial in adding e status, invece Baazar segue senza medaglie. Questi dati vanno presi con le pinze perchè a forza di rilasci e aggiornamenti tutti e tre tendono sempre ad inseguirsi equipareggiandosi quasi come prestazioni.
  • Anche come dimesione del repository vince Git a parità di operazioni sugli stessi file il repository occupa 92 MB rispetto ai 112 MB di bzr e i 179 MB di hg. Questo è dovuto anche dal prossimo punto:
  • Senza entrare veramente nei dettagli e parlandone molto con superficialità si può dire che Git tra diverse versioni dello stesso file archivia le differenze e non gli interi due file come accade invece con bazaar e mercurial. Questa è dovuto ad un differente progetto del sistema.
  • Git sarà più difficile da usare ma sicuramente offre molto di più e in certe cose è decisamente uno strumento potente. Ma non sempre potenti funzioni di branching, merging e tagging sono indispensabili, la seplicità di bazaar a volte può essere un grosso vantaggio.
  • Forse per lo stesso motivo per cui Google ha scelto Mercurial, ovvero la maggior compatibilità con il protocollo HTTP, in rete sembra più facile trovare servizi che offrono hosting gratuito per progetti open source basandosi su hg.
  • Git da parte sua ha github l’hosting per progetti open source che personalmente preferisco in assoluto, diretto concorrente di Google code.

Infine vi lascio con qualche risorsa per i tre DVCS di cui ho parlato. Se vi interessa avere altre infomazioni su questo confronto vi consiglio di visitare Wikipedia inglese, in particolare: Comparison of revision control software e Comparison of open source software hosting facilities

Voi quale sistema di controllo di versione utilizzate? per quale motivo?

Git

Comando: git
Nota storica: Sviluppato da Linus Torvalds che dice di averlo chiamato così perchè “I’m an egotistical bastard, and I name all my projects after myself. First Linux, now git” in inglese git vuol dire qualcosa tipo stupido. E’ scritto in C e Perl
Progetti che lo utilizzano: Linux kernel, GNOME
Applicazione grafica: Tortoisegit (Windows) gitX (Mac OS X)
Sito ufficiale: git-scm.com
Guida: guida ufficiale , libro “Getting Good With Git” in inglese a 19$
Cheat sheet: GitCheatSheet, gitcheatsheet.pdf
Hosting gratutito per progetti open source: github.com, projectlocker.com, sourceforge.net, freepository.com

Mercurial

Comando: hg
Nota storica
: software creato da Matt Mackall e rilasciato con lincenza GNU nacque inzialmente per essere eseguito su Linux, successivamente furono fatte versioni anche per Windows, 2.0. É quasi completamente scritto in Python
Progetti che lo utilizzano: OpenOffice, Mozilla, Symbian
Applicazione grafica: TortoiseHg (Estensione per Windows Explorer e Nautilius), Murky (Mac OS X)
Sito ufficiale: mercurial.selenic.co
Guida: Bellissima guida a mercurial hginit.com (in inglese) Libro con anche ebook gratuito: hgbook.red-bean.com (in inglese)
Cheat sheet: Mercurial-Cheatsheet-Adrian-v1.0.pdf
Hosting gratutito per progetti open source: code.google.com/hosting, sourceforge.net, BerliOS

Bazaar

Comando: bzr
Nota storica: Sponsorizzato dalla canonical il rilascio della prima versione risale al dicembre del 2007 ma la sua storia è molto più lunga e trae origine dal progetto Baz abbandonato da tempo. Anche questo è scritto in Python e C.
Progetti che lo utilizzano: Ubuntu, MySql, Emacs
Applicazione grafica: Bazaar Explorer (multi piattaforma: GNOME, KDE, Windows, Mac OS X)
Sito ufficiale: bazaar.canonical.com
Guida: Guida ufficiale in inglese
Cheat sheet: quick-start-summary.svg
Hosting gratutito per progetti open source: sourceforge.net, launchpad.net

Introduzione al controllo di versione

QUANTE volte scrivendo il codice di un qualsiasi sorgente vi siete accorti che il lavoro delle ultime due ore era del tutto sbagliato e avreste voluto tornare indietro al codice di due ore prima, oppure non riuscite a capire per quale modifica il codice non funziona più. Bè se vi siete trovati in questa situazione allora avete bisogno del controllo di versione.

Il controllo di versione, o version control (VCS), è un software per la gestione di versioni differenti di un qualsiasi tipo di informazione (disegni, sorgenti, libri). In particolare nel campo della programmazione si occupa di tenere traccia di tutte le modifiche apportate ai file sorgente di un progetto software, questo può benissimo essere un sorgente scritto in C oppure un applicazione web o più semplicemente un plugin di WordPress, ma potrebbe benissimo essere un libro che stiamo scrivendo.

Il controllo di versione tenendo traccia di ogni modifica apportata consente di ritornare facilmente a vecchie versioni, di ricordarci ogni modifica che abbiamo apportato e di lavorare su versioni differenti dello stesso sorgente.

Solitamente il controllo di versione si utilizza su architetture di tipo client server. Ovvero c’è un server che contiene i repository (la raccolta di tutti i dati) e i client da remoto ci accedono per scaricare la copia locale su cui lavorare. Una volta finite le modifiche si “ricarica” la copia locale nel repository in modo da archiviare e volendo anche condividere le modifiche. Il modo più veloce per accedere ai repository è tramite linea di comando ma per chi non ci si trovasse bene esistono anche delle interfacce grafiche.

Un altra importantissima caratteristica è il supporto alla stesura collaborativa tra più persone dello stesso progetto, con il controllo di versione è possibile condividere gli stessi file sorgente sempre aggiornati e visualizzare chi ha modificato cosa. Alcuni software semplicemente impediscono a più persone contemporaneamente di modificare lo stesso file (lock) altri invece offrono strumenti (come il merge) per consentire l’unione di modfiche contemporanee dello stesso file e di risolvere eventuali conflitti che ne scaturiscono.

Dopo quest’introduzione vi presento un non esaustivo decisamente “alla mano” glossario e qualche risorsa per Subversione il software di controllo di versione più diffuso. In realtà questo post mi serviva per introdurre il prossimo che pubblicherò, nel quale confronterò tre VCS ovvero Git, Mercurial e Bazaar.

Glossario

Alcuni termini da conoscere che accomunano più o meno tutti i software di controllo di versione.
Commit: operazione con cui si carica la working copy nel repository
Repository: archivio dove risiede il progetto e tutte le revisioni, attraverso il quale è possibile risalire a revisioni precedenti, solitamente ci si accede da remoto.
Working Copy: è la copia locale del progetto a cui stiamo lavorando
Revision: è un numero che identifica ogni commit
Merge: è l’unione di modifiche concorrenti dello stesso file
Checkout: azione che si compie per scaricare in locale la working copy
Tagging: dare un preciso nome di versione ad una revisione
Branching: duplicare i dati sotto controllo di versione per portare avanti sviluppi paralleli dello stesso progetto
Log: registrazione cronologica di ogni operazione effettuata
Diff: comando per visualizzare le differenze tra due diverse revisioni

Subversion

Comando: svn
Nota storica: Naturale sucessore di CVS è nato nel 2000 ed è rilasciato sotto la stessa licenza di Apache. E’ forse il software per il controllo di versione più diffuso. Dal 2009 è stato incluso nei progetti dell’Apache software foundation.
Progetti che lo utilizzano: KDE, GCC, PHP
Applicazione grafica: TortoiseSVN (Windows) SvnX (MAC) kdesvn (KDE)
Sito ufficiale: subversion.apache.org
Guida: libro “Controllo di versione con Subversion” (quasi interamente tradotto in italiano)
Cheat sheet: Subversion-cheat-sheet.png
Hosting gratutito per progetti open source: code.google.com/hosting, projectlocker.com, freepository.com, sourceforge.net, BerliOS
Altro: molto comodo Subclipse il plugin per integrare SVN in Eclipse.

Art. 21 bis – Internet promotore di democrazia

IN dicembre è stato presentato un disegno di legge per introdurre l’articolo 21-bis sul diritto di accesso ad internet nella nostra costituzione. La proposta coofirmata da una ventina di parlamentari (purtroppo per ora non bi-partisan) nasce dall’intervento di Stefano Rodotà all’internet governance forum italia.

In questa occasione il giurista Rodotà ha avanzato la proposta di inserire nella costituzione italiana l’articolo così formulato:

Tutti hanno eguale diritto di accedere alla rete Internet, in condizione di parità, con modalità tecnologicamente adeguate e che rimuovano ogni ostacolo di ordine economico e sociale.

27 parole prodotte dopo un lungo lavoro iniziato su invito di Riccardo Luna (direttore di Wired Italia e già redattore capo de La Repubblica) ideatore della candidatura di Internet al nobel per la pace.

Internet promotore di democrazia

I recenti avvenimenti in nord Africa e quello che ormai accade da molti anni in Cina, e altre decine di casi ci fanno capire come internet sia diventato oltre che uno strumento di sviluppo economico anche un indispensabile mezzo di comunicazione per favorire la libertà d’espressione soprattutto in occasione di dittature palesi e di quelle travestite da democrazia. Più in piccolo il web è un ottimo strumento per la raccolta di pensieri comuni, per l’organizzazione di manifestazioni (vedi famoso popolo viola nato su facebook), per la denuncia di scandali e per lo scambio di idee politiche.

Scritta comparsa sui muri della protesta in Egitto

Scritta comparsa sui muri della protesta in Egitto. Wired.it

Fortunatamente la nostra costituzione già sancisce e protegge la libertà di comunicazione anche in internet infatti l’articolo 21 della costituzione recita: Tutti hanno diritto di manifestare liberamente il proprio pensiero con la parola, lo scritto e ogni altro mezzo di diffusione. La necessità di inserire internet nella costituzione nasce da nuove esigenze.

Con l’avvento della banda larga a basso costo e della sua diffusione, come spiega Rodotà, internet è il più grande spazio pubblico al mondo e si tratta di un vero e proprio promotore di democrazia. Adesso chi non ha accesso ad internet si trova in stato di svantaggio per l’espressione dei propri diritti e per le minori possibilità di sviluppo e di crescita pertanto internet deve diventare un diritto per tutti e bisogna favorirne il più possibile la parità di accesso.

Questo disegno di legge a parere mio è un’ottima proposta che aggiunge più valore alla nostra già bellissima costituzione ed è una cosa molto diversa che andarci a mettere le mani, come qualcuno vorrebbe, per modificare parti già presenti come l’articolo 1.

Privacy

Tutti la vogliono pochi agiscono veramente per averla.

Internet, oltre alla paura della censura e della limitazione da parte di chi detiene il potere, suscita un’altra paura, la paura della violazione della privacy. Per approfondire questo argomento ci vorrebbe troppo tempo, voglio solo dire una cosa. Molti utenti di internet pubblicano su Facebook tutti i loro dati corredati da decine di foto private, accettano in una miriade di siti vari regolamenti sulla privacy spuntando la casella apposta senza neanche leggerli, poi si lamentano della privacy. Di esempi di comportamenti irresponsabili me ne vengono in mente a decine: mandare numeri di carte di credito in form non crittografati o peggio per email, consentire ad applicazioni terze l’accesso a facebook o twitter con i tuoi dati ecc ecc

Secondo me se uno vuole veramente ottenere riservatezza deve pensarci su 5 volte prima di dare qualunque proprio dato a chiunque, poi ovvio che la legge dovrà proteggere i casi di vera e propria invasione della sfera privata. Ma anche qua ci sono numerose pecche.

Da una parte c’è l’utente che vuole la privacy ma non fa nulla per averla e dall’altra la legge italiana piena di incongruenze e arretratissima per la sicurezza della privacy nella tecnologia. Per esempio un servizio di hosting (come Aruba) per ogni sito che ospita deve per legge registrare gli accessi (log di ogni IP con dati temporali) a quel sito, però sempre per legge dovrebbe ad ogni utente di cui registra l’accesso chiedere di firmare una liberatoria. Immaginate voi se dovessero veramente applicare una cosa del genere.

Approfondimenti

Se vi interessa l’argomento vi consiglio la lettura di “Internet è un dono di Dio”, il libro curato da Riccardo Luna è nato dalla campagna Internet for Peace Nobel. Il titolo è una citazione del premo nobel 2010 Liu Xiaobo e contiente 10 storie che spiegano perché Internet è arma di costruzione di massa e nove interventi di governanti, politici, scienziati, artisti che spiegano la rivoluzione pacifica di Internet. Il ricavato del libro sarà devoluto all’associazione One laptop for child. Potete trovarlo a 23€ sul sito di Skira (l’editore) oppure a 26€ (ma costa meno la spedizione) su Amazon.it (con questo link il 10% andrà al mio sito, ma non un cent in meno all’associazione)

Su Repubblica.it vi conisiglio la lettura di “Social web e rivolte popolari tecnologia abbatte censura” parla di vari recenti casi in cui Internet è stato strumento di libertà d’espressione.

Su Wired.it vi consiglio il video dell’intervento di Rodotà all’internet Governance Forum di Roma.

Su InternetCostituzione.it trovate la petizione per inserire internet nella costituzione.

Su questa pagina del Senato e qui sotto trovate il disegno di legge:

Brevissimo Subversion tutorial

HO da poco caricato nel repository di wordpress.org la nuova versione aggiornata del mio plugin FlickrRSS RU ed essendo passato un po di tempo dall’ultima volta che l’ho fatto, ci ho impiegato qualche minuto per ricordarmi bene la procedura. Ecco quindi una brevissima guida per ricordami bene come si fa la prossima volta. In realtà questa guida va benissimo per qualsiasi progetto utilizzi subversion come software di controllo di versione.

Per prima cosa se non avete già una copia in locale sincronizzata (o non vi ricordate dove sia) bisogna scaricare il repository, spostatevi nella cartella dove lo volete scaricare e create una cartella in cui metterlo:

$ mkdir flickrrssRU

poi lanciate il comando per copiarlo tutto in locale

$ svn checkout http://svn.wp-plugins.org/flickrrss-ru flickrrssRU 

l’output sarà qualcosa di simile a questo:

A    flickrrssRU/trunk
A    flickrrssRU/trunk/flickrrssRU.php
A    flickrrssRU/trunk/screenshot-2.png
A    flickrrssRU/trunk/flickrrssRU-settingspage.php
A    flickrrssRU/trunk/readme.txt
A    flickrrssRU/trunk/screenshot-1.png
A    flickrrssRU/branches
A    flickrrssRU/tags

spostatevi nella cartella della copia locale, per esempio nel mio caso

$ cd /var/www/flickrrssRU 

e controllate che sia aggiornata all’ultima versione sul repository. Nel caso ci siano più persone che lavorano allo stesso plugin (più in generale allo stesso progetto) potrebbe essere che non lo sia, ovviamente qualcuno potrebbe aver modificato il progetto. Se invece l’avete appena scaricato sarà sicuramente aggiornato.

$ svn update

se state per rilasciare una nuova versione del progetto, e non dovete solo apportare delle modifiche minori, prima di tutto bisogna taggare la versione attuale in modo da renderla fissa nel tempo. Per esempio nel caso la nuova versione aggiunga delle nuove funzioni, a qualcuno potrebbero non interessare, o un altro caso molto più comune è per la compatibilità, se nella versione che state andando a rilasciare sono state fatte delle grosse modifiche potebbe non funzionare più con alcune applicazioni, pertanto qualcuno in questi casi vorrà comunque continuare ad utilizzare le vesioni precedenti.

Per fare questo copiamo il contenuto della cartella trunk (quindi l’attuale versione del progetto da taggare) in una sottocartella di tags nominata con la versione che stiamo andando ad “archiviare”

$ svn copy trunk tags/0.2 

ora possiamo aggiornare e modificare i file che si trovano nella cartella trunk con i file della nuova versione. Ricordatevi se state rilasciando una nuova versione di un plugin per WP di modificare i numeri di versione anche all’interno del file readme. Una volta che avete inserito nella cartella trunk i file aggiornati se avete aggiunto dei nuovi file che prima non c’erano dovete lanciare questo comando:

$ svn add trunk/nome_nuovo_file

oppure se dovete eliminare dei file:

$ svn delete trunk/nome_file_da_rimuovere

Ora per finire bisogna caricare tutte le modifiche effettuate ovvero effettuare il COMMIT. Con esso tutte le modifiche effettuate sui dati vengono memorizzate. Il -m serve per poter personalizzare il messaggio di log ovvero il testo messo tra virgolette, è un aiuto quando si va a vedere il log del repository per ricordarsi le modifiche che sono state effettuate ad ogni commit.

$ svn commit -m "tagging version 0.2"

Comandi Subversion

Vi lascio la lista dei principali comandi di subversion (rigorosamente da lanciare preceduti dal comando svn) con una brevissima descrizione, per vedere bene come funzionano basta lanciare il comando:

$ svn help nome-del-comando

i comandi scritti tra parentesi tonde sono gli equivalenti meno user-friendly ma più veloci

add Aggiunge file e directory al controllo di versione
blame (praise, annotate, ann) Restituisce il contenuto dei file specificato con varie informazioni
cat Restituisce il contenuto dei file specificato
checkout (co) Copia in locale una working copy
commit (ci) Trasmette le modifiche della copia locale al repository
copy (cp) Copia file o cartelle da un sorgente ad una destinazione
delete (del, remove, rm) Rimuove file o cartelle dal controllo di versione
diff (di) Mostra le differenze tra due revisioni
export Crea una copia senza metterla sotto controllo di versione
help (?, h) Descrive l’uso di un comando
import Esegue il commit di un percorso non sotto il controllo di versione
info Mostra varie informazioni
list (ls) Elenca il contenuto della directory nel repository
lock Blocca cartelle e file nel repository dalla modifica da parte di altri utenti
log Mostra i log di un file o dell’intero repository
merge unisce varie modifiche dello stesso file
mergeinfo mostra le info relative al merge
mkdir crea una cartella nel repository
move (mv, rename, ren) sposta o rinomina file e cartelle
status (stat, st) Mostra lo stato attuale tra la copia locale e il repository
unlock Sblocca i percorsi o i file bloccati con lock
update (up) Aggiorna la copia locale con quella del repository

Ed ecco un “cheat sheet” per subversion: