Nessun risultato. Prova con un altro termine.
Guide
Notizie
Software
Tutorial

I termini fondamentali

Entrare nella terminologia di versioning usata da Subversion
Entrare nella terminologia di versioning usata da Subversion
Link copiato negli appunti

Abbiamo già utilizzato alcuni termini che specificano le azioni da compiere con un sistema di versionamento, entriamo nel merito della terminologia usata da Subversion, per capire meglio operazioni, comandi e concetti che ci saranno utili nel corso della guida.

Il primo è più importante concetto è quello del repository: il deposito dove risiedono i nostri dati. È possibile creare diversi repository su ogni server Subversion; vedremo come ciascuno di essi sia accessibile con un URL specifico.

Per lavorare sui file si utilizza il client SVN per creare una copia di lavoro locale. Tale copia è quella su cui vengono effettuate le vere e proprie modifiche, che poi verranno caricate sul server.

La creazione di una nuova copia di lavoro locale è detta checkout. Contrariamente ad altri sistemi di controllo di versione, in Subversion tale operazione non blocca niente sul server: semplicemente estrae i file per permetterci di cominciare a lavorare su di essi. Si possono fare quanti checkout si vogliono, anche solo per consultazione, eliminando poi la copia locale quando non ci serve più.

Il caricamento delle modifiche locali sul server è detto commit. È quando effettuiamo un commit che entra in gioco il "filtro" di Subversion, con l'obiettivo di controllare e segnalare se le nostre modifiche vadano in conflitto con altre già presenti sul repository.

Ogni commit andato a buon fine genera una nuova revisione, ovvero aumenta di 1 il numero di revisione del repository. Ogni repository parte alla revisione 0.

L'aggiornamento di una copia locale già esistente è detto update. In maniera opposta al commit, si occupa di applicare alla nostra copia di lavoro le ultime modifiche caricare sul repository.

Le operazioni di checkout, commit e update si effettuano con gli omonimi comandi.

I rami (branches) sono versioni separate del progetto, solitamente diversificate per permettere l'implementazione di aggiunte o modifiche rispetto al ramo principale, mantenendo tale ramo principale intatto.

Le etichette (tag) sono un modo per "fissare" definitivamente una revisione che ha un significato particolare, ad esempio il primo rilascio di un progetto. Per non doversi ricordare il numero di revisione, si può etichettare (appunto) la revisione con un nome specifico che risulti mnemonico per noi (es. "Versione di rilascio").

Nota: se "ramo" è una traduzione accettabile e abbastanza univoca dell'originale "branch", per il termine "tag" la questione è più complicata. "Etichetta" ci sembra forse la migliore scelta, nonostante nella guida ufficiale in italiano si usi il termine "targa", forse per assonanza. Di certo, vista la diffusione del termine originale anche nel nostro linguaggio, tutti vi capiranno se parlate di "revisioni taggate". Nel resto di questa guida useremo i termini "etichetta" e "tag" come sinonimi.


Ti consigliamo anche