Controllo di versione con Subversion

All version control systems have to solve the same fundamental problem: how will the system allow users to share information, but prevent them from accidentally stepping on each other's feet? It's all too easy for users to accidentally overwrite each other's changes in the repository.

Tutti i sistemi per il controllo di versione devono risolvere lo stesso problema fondamentale: come farà il sistema a permettere agli utenti di condividere le informazioni, evitando al contempo che questi possano accidentalmente interferire fra loro? È troppo semplice infatti per gli utenti sovrascrivere accidentalmente le modifiche degli altri nel repository.

Consider the scenario shown in Figura 2.2, «Il problema da evitare». Suppose we have two co-workers, Harry and Sally. They each decide to edit the same repository file at the same time. If Harry saves his changes to the repository first, then it's possible that (a few moments later) Sally could accidentally overwrite them with her own new version of the file. While Harry's version of the file won't be lost forever (because the system remembers every change), any changes Harry made won't be present in Sally's newer version of the file, because she never saw Harry's changes to begin with. Harry's work is still effectively lost—or at least missing from the latest version of the file—and probably by accident. This is definitely a situation we want to avoid!

Si consideri lo scenario illustrato in Figura 2.2, «Il problema da evitare». Supponiamo di avere 2 collaboratori, che chiameremo Hally e Sally. Entrambi decidono di modificare lo stesso file del repository nello stesso momento. Se Harry salva le sue modifiche nel repository per primo, è possibile che (qualche istante dopo) Sally possa accidentalmente sovrascriverle con la propria versione aggiornata del file. Mentre la versione di Harry del file non verrà persa per sempre (perché il sistema ricorda ogni cambiamento), qualsiasi cambiamento apportato da Harry non sarà presente nella nuova versione del file di Sally, perché lei non ha mai ricevuto le modifiche di Harry da cui poter continuare. Il lavoro di Harry è effettivamente perso—o quantomeno mancante dall'ultima versione del file—e probabilmente accidentalmente. Questa è sicuramente la situazione che si vuole evitare.

Figura 2.2. Il problema da evitare

Many version control systems use a lock-modify-unlock model to address the problem of many authors clobbering each other's work. In this model, the repository allows only one person to change a file at a time. This exclusivity policy is managed using locks. Harry must “lock” a file before he can begin making changes to it. If Harry has locked a file, then Sally cannot also lock it, and therefore cannot make any changes to that file. All she can do is read the file, and wait for Harry to finish his changes and release his lock. After Harry unlocks the file, Sally can take her turn by locking and editing the file. Figura 2.3, «La soluzione blocca-modifica-sblocca» demonstrates this simple solution.

Molti sistemi per il controllo di versione usano un modello blocca-modifica-sblocca per trattare il potenziale problema di più autori che compromettono il proprio lavoro. In questo modello, il repository permette solo ad una persona alla volta di modificare un file. Questa politica di esclusione è gestita attraverso dei blocchi (lock). Harry deve «bloccare» un file prima di apportare modifiche allo stesso. Se Harry ha bloccato il file, Sally non potrà a sua volta bloccarlo, e quindi non potrà apportare modifiche allo stesso. Tutto quello che può fare è leggere il file ed aspettare che Harry abbia finito le sue modifiche e rilasci il suo blocco. Dopo che Harry avrà sbloccato il file, Sally potrà prendere il suo turno bloccando e modificando il file. Figura 2.3, «La soluzione blocca-modifica-sblocca» dimostra questa semplice soluzione.

Figura 2.3. La soluzione blocca-modifica-sblocca

The problem with the lock-modify-unlock model is that it's a bit restrictive, and often becomes a roadblock for users:

Il problema con il modello blocca-modifica-sblocca è che risulta un po' restrittivo, e spesso diventa come un ostacolo per gli utenti:

Subversion, CVS, and other version control systems use a copy-modify-merge model as an alternative to locking. In this model, each user's client contacts the project repository and creates a personal working copy—a local reflection of the repository's files and directories. Users then work in parallel, modifying their private copies. Finally, the private copies are merged together into a new, final version. The version control system often assists with the merging, but ultimately a human being is responsible for making it happen correctly.

Subversion, CVS, ed altri sistemi per il controllo di versione usano il modello copia-modifica-fondi come alternativa al blocco. In questo modello, il client di ogni utente comunica con il repository e crea la propria copia di lavoro—una riproduzione dei file e delle directory del repository. Gli utenti possono poi lavorare in parallelo, modificando le proprie copie private. Infine, le copie private vengono fuse in una nuova versione finale. Spesso il sistema per il controllo di versione assiste nella fase di integrazione, ma alla fine è un essere umano il responsabile di fare in modo che questa si compia correttamente.

Here's an example. Say that Harry and Sally each create working copies of the same project, copied from the repository. They work concurrently, and make changes to the same file A within their copies. Sally saves her changes to the repository first. When Harry attempts to save his changes later, the repository informs him that his file A is out-of-date. In other words, that file A in the repository has somehow changed since he last copied it. So Harry asks his client to merge any new changes from the repository into his working copy of file A. Chances are that Sally's changes don't overlap with his own; so once he has both sets of changes integrated, he saves his working copy back to the repository. Figura 2.4, «La soluzione copia-modifica-fondi» and Figura 2.5, «La soluzione copia-modifica-fondi (continua)» show this process.

Ecco un esempio. Supponiamo che Harry e Sally creino una copia locale dello stesso progetto, copiata dallo stesso repository. Loro lavorano concorrentemente, ed apportano modifiche allo stesso file A all'interno delle loro copie. Sally salva le proprie modifiche per prima sul repository. Quando Harry prova successivamente a salvare i propri cambiamenti, il repository lo informa che il suo file A è obsoleto. In altre parole, questo file A è cambiato nel repository rispetto all'ultima volta che lui lo ha copiato. Quindi Harry chiede al repository di fondere ogni nuovo cambiamento dal repository alla sua copia locale del file A. Con buona probabilità i cambiamenti di Sally non si sovrappongono con i suoi; quindi una volta che ha integrato entrambi gli insiemi di cambiamenti, salva la sua copia di lavoro nel repository. Figura 2.4, «La soluzione copia-modifica-fondi» e Figura 2.5, «La soluzione copia-modifica-fondi (continua)» mostrano questo processo.

Figura 2.4. La soluzione copia-modifica-fondi

Figura 2.5. La soluzione copia-modifica-fondi (continua)

But what if Sally's changes do overlap with Harry's changes? What then? This situation is called a conflict, and it's usually not much of a problem. When Harry asks his client to merge the latest repository changes into his working copy, his copy of file A is somehow flagged as being in a state of conflict: he'll be able to see both sets of conflicting changes, and manually choose between them. Note that software can't automatically resolve conflicts; only humans are capable of understanding and making the necessary intelligent choices. Once Harry has manually resolved the overlapping changes—perhaps after a discussion with Sally—he can safely save the merged file back to the repository.

Cosa accade se le modifiche di Sally di fatto si sovrappongono a quelle di Harry? Che comporta? Questa situazione è chiamataconflitto, ed in generale non è un grande problema. Quando Harry chiede al proprio client di fondere le ultime modifiche del repository nella sua copia di lavoro, la propria copia del file A è in qualche modo etichettata come in uno stato di conflitto: lui sarà in grado di vedere entrambi gli insiemi di cambiamenti e scegliere manualmente tra questi. Da notare che il software non può risolvere il conflitto automaticamente; solo gli uomini sono capaci di capire e fare le necessarie scelte intelligenti. Una volta che Harry ha risolto manualmente i cambiamenti sovrapposti— probabilmente dopo una discussione con Sally— può salvare in maniera sicura il file integrato nel repository.

The copy-modify-merge model may sound a bit chaotic, but in practice, it runs extremely smoothly. Users can work in parallel, never waiting for one another. When they work on the same files, it turns out that most of their concurrent changes don't overlap at all; conflicts are infrequent. And the amount of time it takes to resolve conflicts is far less than the time lost by a locking system.

Il modello copia-modifica-fondi può sembrare un po' caotico, ma nella pratica funziona senza difficoltà. L'utente può lavorare in parallelo, senza mai dover aspettare gli altri. Quando gli utenti lavorano sullo stesso file, accade frequentemente che la maggior parte delle modifiche concorrenti non si sovrappongano; i conflitti sono infatti rari. La quantità di tempo necessario per risolvere i conflitti è decisamente inferiore a quella persa nell'uso di un sistema di blocchi.

In the end, it all comes down to one critical factor: user communication. When users communicate poorly, both syntactic and semantic conflicts increase. No system can force users to communicate perfectly, and no system can detect semantic conflicts. So there's no point in being lulled into a false promise that a locking system will somehow prevent conflicts; in practice, locking seems to inhibit productivity more than anything else.

Alla fine, tutto si riconduce ad un fattore critico: la comunicazione degli utenti. Quando la comunicazione è povera, sia i conflitti sintattici che semantici aumentano. Nessun sistema può forzare l'utente a comunicare perfettamente, e nessun sistema può scovare conflitti semantici. Non c'è quindi nessuna ragione per rimanere illusi dalla falsa promessa che il sistema a blocchi prevenga in qualche modo i conflitti; nella pratica, il blocco sembra più che altro limitare la produttività.

You've already read about working copies; now we'll demonstrate how the Subversion client creates and uses them.

Si è già letto a proposito delle copie di lavoro; adesso verrà mostrato come queste vengano create ed utilizzate dal client Subversion.

A Subversion working copy is an ordinary directory tree on your local system, containing a collection of files. You can edit these files however you wish, and if they're source code files, you can compile your program from them in the usual way. Your working copy is your own private work area: Subversion will never incorporate other people's changes, nor make your own changes available to others, until you explicitly tell it to do so. You can even have multiple working copies of the same project.

Una copia di lavoro di Subversion è un normale albero di directory sul proprio sistema locale, contenente un certo insieme di file. È possibile modificare questi file come si preferisce, e, se si tratta di file di codice sorgente, si può compilare il proprio programma esattamente nella maniera usuale. La copia di lavoro è la propria area personale di lavoro: Subversion non incorporerà mai le modifiche introdotte da altri, né renderà le proprie modifiche disponibili ad altri, fino a quando non verrà esplicitamente chiesto di farlo. È possibile perfino avere più di una copia di lavoro dello stesso progetto.

After you've made some changes to the files in your working copy and verified that they work properly, Subversion provides you with commands to “publish” your changes to the other people working with you on your project (by writing to the repository). If other people publish their own changes, Subversion provides you with commands to merge those changes into your working directory (by reading from the repository).

Dopo aver apportato le modifiche desiderate ai file nella propria copia di lavoro ed aver verificato che funzionino correttamente, Subversion mette a disposizione dei comandi per «pubblicare» le proprie modifiche verso le altre persone che lavorano sullo stesso progetto (scrivendo nel repository). Quando altre persone pubblicano le loro modifiche, Subversion permette di importarle nella propria directory di lavoro (leggendole dal repository).

A working copy also contains some extra files, created and maintained by Subversion, to help it carry out these commands. In particular, each directory in your working copy contains a subdirectory named .svn, also known as the working copy administrative directory. The files in each administrative directory help Subversion recognize which files contain unpublished changes, and which files are out-of-date with respect to others' work.

Una copia di lavoro contiene anche dei file aggiuntivi, creati ed aggiornati da Subversion, come supporto all'esecuzione dei comandi di cui sopra. In particolare, ogni directory nella propria copia di lavoro contiene una sottodirectory chiamata .svn, altrimenti nota come directory amministrativa della copia di lavoro. I file presenti in ciascuna delle directory amministrative aiutano Subversion a tenere traccia di quali file contengono modifiche non pubblicate e quali file non sono aggiornati rispetto al lavoro svolto da altri.

A typical Subversion repository often holds the files (or source code) for several projects; usually, each project is a subdirectory in the repository's filesystem tree. In this arrangement, a user's working copy will usually correspond to a particular subtree of the repository.

Un tipico repository di Subversion spesso contiene i file (o codice sorgente) di diversi progetti; di solito, ogni progetto è contenuto in una sottodirectory nell'albero del filesystem del repository. Seguendo questa disposizione, la copia di lavoro di un utente corrisponderà ad uno specifico sottoalbero del repository.

For example, suppose you have a repository that contains two software projects, paint and calc. Each project lives in its own top-level subdirectory, as shown in Figura 2.6, «Il filesystem del repository».

Ad esempio, supponiamo di avere un repository che contenga due progetti software, paint e calc. Ciascun progetto vive nella sua personale sottodirectory al livello più alto dell'albero del filesystem, come mostrato in Figura 2.6, «Il filesystem del repository».

Figura 2.6. Il filesystem del repository

To get a working copy, you must check out some subtree of the repository. (The term “check out” may sound like it has something to do with locking or reserving resources, but it doesn't; it simply creates a private copy of the project for you.) For example, if you check out /calc, you will get a working copy like this:

Per ottenere una copia di lavoro, si deve anzitutto eseguire il check out di un qualche sottoalbero del repository. (Il termine «check out» potrebbe erroneamente far pensare ad una azione di blocco o riserva delle risorse ma, in realtà, crea semplicemente all'utente una copia di lavoro del progetto.) Per esempio, se si effettua il check out di /calc, si otterrà una copia di lavoro con questa struttura:

$ svn checkout http://svn.example.com/repos/calc
A    calc/Makefile
A    calc/integer.c
A    calc/button.c
Checked out revision 56.

$ ls -A calc
Makefile  integer.c  button.c  .svn/

The list of letter A's indicates that Subversion is adding a number of items to your working copy. You now have a personal copy of the repository's /calc directory, with one additional entry—.svn—which holds the extra information needed by Subversion, as mentioned earlier.

La lista di A indica che Subversion stia aggiungendo un certo numero di elementi alla propria copia locale. Adesso quindi si ha una copia personale della directory/calc del repository, con un elemento aggiuntivo —.svn—che contiene tutte quelle extra informazioni menzionate in precedenza.

Suppose you make changes to button.c. Since the .svn directory remembers the file's modification date and original contents, Subversion can tell that you've changed the file. However, Subversion does not make your changes public until you explicitly tell it to. The act of publishing your changes is more commonly known as committing (or checking in) changes to the repository.

Supponiamo di aver apportato modiche a button.c. Dato che la directory .svn ricorda le date delle modifiche ai file ed i contenuti originali, Subversion può notificare che i file siano stati cambiati. Ad ogni modo, Subversion non rende pubblici i propri cambiamenti fino a quando non verrà esplicitamente richiesto. L'atto di pubblicazione dei propri cambiamenti è comunemente conosciuta comecommit (o check in) delle modifiche al repository.

To publish your changes to others, you can use Subversion's commit command:

Per pubblicare le proprie modifiche agli altri è possibile usare il comando di Subversion commit:

$ svn commit button.c
Sending        button.c
Transmitting file data .
Committed revision 57.

Now your changes to button.c have been committed to the repository; if another user checks out a working copy of /calc, they will see your changes in the latest version of the file.

Adesso le modifiche a button.c sono state sottomesse al repository; se un altro utente effettua il check out di una copia di lavoro di /calc, vedrà i propri cambiamenti nell'ultima versione del file.

Suppose you have a collaborator, Sally, who checked out a working copy of /calc at the same time you did. When you commit your change to button.c, Sally's working copy is left unchanged; Subversion only modifies working copies at the user's request.

Supponiamo di avere un altro collaboratore, Sally, che ha effettuato il check out della copia di lavoro di /calc nello stesso momento in cui è stata effettuata la nostra. Quando verranno sottomesse le modifiche al filebutton.c, la copia di lavoro di Sally rimarrà inalterata; Subversion infatti modifica le copie solamente alla richiesta dell'utente.

To bring her project up to date, Sally can ask Subversion to update her working copy, by using the Subversion update command. This will incorporate your changes into her working copy, as well as any others that have been committed since she checked it out.

Per attualizzare il proprio progetto, Sally può chiedere a Subversion di aggiornare la sua copia di lavoro, usando il comando di Subversion update. Questo incorporerà le nostre modifiche nella sua copia di lavoro, così come ogni altro cambiamento che è stato sottomesso da quando lei ha effettuato il check out.

$ pwd
/home/sally/calc

$ ls -A
.svn/ Makefile integer.c button.c

$ svn update
U    button.c
Updated to revision 57.

The output from the svn update command indicates that Subversion updated the contents of button.c. Note that Sally didn't need to specify which files to update; Subversion uses the information in the .svn directory, and further information in the repository, to decide which files need to be brought up to date.

I risultati del comando svn update indicano che Subversion ha aggiornato i contenuti di button.c. Si noti che Sally non ha dovuto specificare quali file aggiornare; Subversion usa le informazioni nella directory .svn, ed informazioni aggiuntive nel repository, per decidere quali file hanno bisogno di essere attualizzati.

An svn commit operation can publish changes to any number of files and directories as a single atomic transaction. In your working copy, you can change files' contents, create, delete, rename and copy files and directories, and then commit the complete set of changes as a unit.

Un comando svn commit può pubblicare i cambiamenti.

In the repository, each commit is treated as an atomic transaction: either all the commit's changes take place, or none of them take place. Subversion tries to retain this atomicity in the face of program crashes, system crashes, network problems, and other users' actions.

Nel repository, ogni commit viene trattata come una transazione atomica: vengono effettuate o tutte o nessuna delle modifiche. Subversion cerca di mantenere questa atomicità come precauzione verso i crash dei programmi, i crash dei sistemi, i problemi di rete ed altre azioni dell'utente.

Each time the repository accepts a commit, this creates a new state of the filesystem tree, called a revision. Each revision is assigned a unique natural number, one greater than the number of the previous revision. The initial revision of a freshly created repository is numbered zero, and consists of nothing but an empty root directory.

Ogni volta che il repository accetta una commit, questo crea un nuovo stato nell'albero del filesystem, che viene chiamato revisione. Ogni revisione è assegnata ad un unico numero naturale, di una unità maggiore rispetto alla revisione precedente. La revisione iniziale di un repository appena creato è numerata come zero, e consiste in nient'altro che una directory radice vuota.

Figura 2.7, «Il repository» illustrates a nice way to visualize the repository. Imagine an array of revision numbers, starting at 0, stretching from left to right. Each revision number has a filesystem tree hanging below it, and each tree is a “snapshot” of the way the repository looked after a commit.

Figura 2.7, «Il repository» illustra una tipo intuitivo di visualizzazione del repository. Si immagini un array di numeri di revisioni, che inizia da 0 ed incrementa da destra a sinistra. Ogni numero di revisione ha un albero di filesystem appeso al di sotto, e ogni albero è una «istantanea» di come appariva il repository dopo la commit.

Figura 2.7. Il repository

It's important to note that working copies do not always correspond to any single revision in the repository; they may contain files from several different revisions. For example, suppose you check out a working copy from a repository whose most recent revision is 4:

È importante notare che le copie di lavoro non sempre corrispondano ad una singola revisione del repository; potrebbero contenere file di varie revisioni differenti. Ad esempio, supponiamo di effettuare check out di una copia di lavoro da un repository la cui revisione più recente è 4:

calc/Makefile:4
     integer.c:4
     button.c:4

At the moment, this working directory corresponds exactly to revision 4 in the repository. However, suppose you make a change to button.c, and commit that change. Assuming no other commits have taken place, your commit will create revision 5 of the repository, and your working copy will now look like this:

Al momento, questa directory di lavoro corrisponde esattamente alla revisione 4 del repository. Tuttavia, supponiamo di aver modificato button.c, ed aver sottomesso questo cambiamento. Assumendo che nessun'altra commit abbia avuto luogo, la propria commit creerà la revisione 5 del repository, e la propria copia di lavoro apparirà come segue:

calc/Makefile:4
     integer.c:4
     button.c:5

Suppose that, at this point, Sally commits a change to integer.c, creating revision 6. If you use svn update to bring your working copy up to date, then it will look like this:

Supponiamo che, a questo punto, Sally effettui la commit di una modifica a integer.c, creando la revisione 6. Se si usa svn update per attualizzare la propria copia di lavoro, questa apparirà come segue:

calc/Makefile:6
     integer.c:6
     button.c:6

Sally's change to integer.c will appear in your working copy, and your change will still be present in button.c. In this example, the text of Makefile is identical in revisions 4, 5, and 6, but Subversion will mark your working copy of Makefile with revision 6 to indicate that it is still current. So, after you do a clean update at the top of your working copy, it will generally correspond to exactly one revision in the repository.

La modifica di Sally a integer.c apparirà nella propria copia di lavoro, ed i propri cambiamenti saranno ancora presenti in button.c. In questo esempio il testo di Makefile è identico nelle revisioni 4, 5 e 6, ma Subversion marcherà la propria copia di lavoro di Makefile con la revisione 6 per indicare che è la corrente. Quindi, dopo aver fatto un aggiornamento al livello più alto della propria copia di lavoro, questa corrisponderà esattamente ad una revisione del repository.

For each file in a working directory, Subversion records two essential pieces of information in the .svn/ administrative area:

Per ogni file nella directory di lavoro, Subversion registra due porzioni di informazione essenziali nell'area di amministrazione .svn/:

Given this information, by talking to the repository, Subversion can tell which of the following four states a working file is in:

Date queste informazioni, comunicando con il repository, Subversion può decidere in quale dei seguenti quattro stati si trovi un file nella copia di lavoro:

This may sound like a lot to keep track of, but the svn status command will show you the state of any item in your working copy. For more information on that command, see sezione chiamata «svn status».

Potrebbe sembrare eccessivo tener traccia di tutto questo, ma il comando svn status mostrerà la stato di ogni elemento nella copia di lavoro. Per altre informazioni su questo comando, si veda sezione chiamata «svn status».

As a general principle, Subversion tries to be as flexible as possible. One special kind of flexibility is the ability to have a working copy containing files and directories with a mix of different working revision numbers. Unfortunately, this flexibility tends to confuse a number of new users. If the earlier example showing mixed revisions perplexed you, here's a primer on both why the feature exists and how to make use of it.

Come principio generale, Subversion vuole essere il più flessibile possibile. Una particolare flessibilità deriva dalla possibilità di avere una copia di lavoro contenente file e directory con un insieme di differenti numeri di revisione. Sfortunatamente questa flessibilità tende a confondere alcuni utenti. Segue quindi un'introduzione sul perché esiste questa caratteristica e su come utilizzarla.

When you create a new Subversion repository, it begins its life at revision zero and each successive commit increases the revision number by one. After your commit completes, the Subversion client informs you of the new revision number:

Quando si crea un nuovo repository Subversion, questo comincia la sua vita dalla revisione zero ed ogni successivo commit incrementa il numero di revisione di uno. Quando si completa la commit, il client Subversion comunica il nuovo numero della revisione:

        $ svn commit --message "Corrected number of cheese slices."
        Sending        sandwich.txt
        Transmitting file data .
        Committed revision 3.
      

If at any point in the future you want to refer to that revision (we'll see how and why we might want to do that later in this chapter), you can refer to it as “3”.

Se ad un certo punto in futuro ci si vorrà riferire a quella particolare revisione (si vedrà come e perché si dovrebbe volerlo nel seguito di questo capitolo), ci si potrà riferire ad essa con il numero «3».

The Subversion client understands a number of revision keywords. These keywords can be used instead of integer arguments to the --revision switch, and are resolved into specific revision numbers by Subversion:

Il client Subversion riconosce un numero di chiavi di revisioni. Queste chiavi possono essere usate al posto degli argomenti interi con l'opzione --revision, e vengono risolte da Subversion in specifici numeri di revisione:

Nota

Each directory in your working copy contains an administrative subdirectory called .svn. For every file in a directory, Subversion keeps a copy of each file in the administrative area. This copy is an unmodified (no keyword expansion, no end-of-line translation, no nothing) copy of the file as it existed in the last revision (called the “BASE” revision) that you updated it to in your working copy. We refer to this file as the pristine copy or text-base version of your file, and it's always an exact byte-for-byte copy of the file as it exists in the repository. Ogni directory della propria copia di lavoro contiene una sottodirectory di amministrazione chiamata .svn. Per ogni file in una directory, Subversion mantiene una copia nell'area d'amministrazione. Questa copia non modificata da parte di Subversion (nessuna espansione delle chiavi, nessuna conversione dei fine riga, niente) è una copia dell'ultima revisione del file (chiamata revisione «BASE») che è stata aggiornata nella propria copia di lavoro. Ci si riferirà a questo file come alla revisione copia di ripristino oppure testo base, ed è sempre una copia esatta byte per byte del file che si trova nel repository.

	Nota
	PREV, BASE, and COMMITTED can be used to refer to local paths, but not to URLs. PREV, BASE e COMMITTED possono essere usati per far riferimento a percorsi locali ma non a URL.

Here are some examples of revision keywords in action. Don't worry if the commands don't make sense yet; we'll be explaining these commands as we go through the chapter:

Diamo alcuni esempi di chiavi di revisione in azione. Non bisogna preoccuparsi se i comandi sembrano non aver senso; saranno spiegati in seguito.

$ svn diff --revision PREV:COMMITTED foo.c
# shows the last change committed to foo.c

$ svn log --revision HEAD
# shows log message for the latest repository commit

$ svn diff --revision HEAD
# compares your working file (with local changes) to the latest version
# in the repository

$ svn diff --revision BASE:HEAD foo.c
# compares your «pristine» foo.c (no local changes) with the
# latest version in the repository

$ svn log --revision BASE:HEAD
# shows all commit logs since you last updated

$ svn update --revision PREV foo.c
# rewinds the last change on foo.c
# (foo.c's working revision is decreased)

These keywords allow you to perform many common (and helpful) operations without having to look up specific revision numbers or remember the exact revision of your working copy.

Queste chiavi permettono di effettuare le più comuni (ed utili) operazioni senza bisogno di specificare i numeri di revisione o di ricordare l'esatta revisione della propria copia di lavoro.

Anywhere that you specify a revision number or revision keyword, you can also specify a date inside curly braces “{}”. You can even access a range of changes in the repository using both dates and revisions together!

Ovunque si specifichi un numero di revisione o una chiave di revisione, si può anche specificare una data racchiusa fra parentesi graffe «{}». Sarà addirittura possibile accedere ad un insieme di cambiamenti nel repository usando assieme le date e le revisioni!

Here are examples of the date formats that Subversion accepts. Remember to use quotes around any date that contains spaces.

Qui potete trovare alcuni esempi di formati di data accettati da Subversion. Ricordatevi di racchiudere la data tra doppi apici se al suo interno sono presenti degli spazi.

$ svn checkout --revision {2002-02-17}
$ svn checkout --revision {15:30}
$ svn checkout --revision {15:30:00.200000}
$ svn checkout --revision {"2002-02-17 15:30"}
$ svn checkout --revision {"2002-02-17 15:30 +0230"}
$ svn checkout --revision {2002-02-17T15:30}
$ svn checkout --revision {2002-02-17T15:30Z}
$ svn checkout --revision {2002-02-17T15:30-04:00}
$ svn checkout --revision {20020217T1530}
$ svn checkout --revision {20020217T1530Z}
$ svn checkout --revision {20020217T1530-0500}
…

When you specify a date as a revision, Subversion finds the most recent revision of the repository as of that date:

Quando si speicifica una data come revisione, Subversion trova la più recente revisione del repository registrata fino a quella specifica data:

$ svn log --revision {2002-11-28}
------------------------------------------------------------------------
r12 | ira | 2002-11-27 12:31:51 -0600 (Wed, 27 Nov 2002) | 6 lines
…

You can also use a range of dates. Subversion will find all revisions between both dates, inclusive:

Si può anche usare un intervallo di date. Subversion troverà tutte le revisioni comprese tra le due date (estremi compresi):

$ svn log --revision {2002-11-20}:{2002-11-29}
…

As we pointed out, you can also mix dates and revisions:

Come abbiamo visto, è possibile combinare le date e le revisioni:

$ svn log --revision {2002-11-20}:4040

Users should be aware of a subtlety that can become quite a stumbling-block when dealing with dates in Subversion. Since the timestamp of a revision is stored as a property of the revision—an unversioned, modifiable property—revision timestamps can be changed to represent complete falsifications of true chronology, or even removed altogether. This will wreak havoc on the internal date-to-revision conversion that Subversion performs.

Gli utenti dovrebbero fare attenzione ad una sottigliezza che si potrebbe rilevare un ostacolo quando si utilizzano le date in Subversion. Poiché il timestamp di una revisione è salvato come una proprietà della revisione — una proprietà modificabile e non gestita dal sistema di controllo di versione — i timestamp di revisione possono essere modificati per falsificare completamente l'ordine cronologico, o possono essere rimossi completamente. Questo porterà problemi sul sistema di conversione data-revisione utilizzato da Subversion.

When working on a project with a team, you'll want to update your working copy to receive any changes made since your last update by other developers on the project. Use svn update to bring your working copy into sync with the latest revision in the repository.

Quando si lavora ad un progetto in gruppo, si dovrà aggiornare la propria copia di lavoro per ricevere tutte le modifiche fatte, dopo l'ultimo aggiornamento, dagli altri sviluppatori. Si usa il comando svn update per allineare la propria copia di lavoro con l'ultima versione nel repository.

$ svn update
U  foo.c
U  bar.c
Updated to revision 2.

In this case, someone else checked in modifications to both foo.c and bar.c since the last time you updated, and Subversion has updated your working copy to include those changes.

In questo caso, qualcun altro ha effettuato delle modifiche ad entrambi i file foo.c e bar.c dall'ultima volta che si è fatto l'update e Subversion ha aggiornato la copia di lavoro per includere queste modifiche.

Let's examine the output of svn update a bit more. When the server sends changes to your working copy, a letter code is displayed next to each item to let you know what actions Subversion performed to bring your working copy up-to-date:

Andiamo ad esaminare un po' meglio l'output del comando svn update. Quando il server invia le modifiche alla propria copia di lavoro, viene visualizzata una lettera subito prima di ogni elemento per indicare l'azione compiuta da Subversion per aggiornare la copia di lavoro:

Now you can get to work and make changes in your working copy. It's usually most convenient to decide on a particular change (or set of changes) to make, such as writing a new feature, fixing a bug, etc. The Subversion commands that you will use here are svn add, svn delete, svn copy, and svn move. However, if you are merely editing files that are already in Subversion, you may not need to use any of these commands until you commit. Changes you can make to your working copy:

A questo punto si è in grado di lavorare ed apportare modifiche alla propria copia di lavoro. Di solito è più conveniente decidere un particolare cambiamento (o un insieme di cambiamenti) da fare, come se si dovesse scrivere una nuova caratteristica, fissare un bug, etc. I comandi Subversion da usare sono svn add, svn delete, svn copy e svn move. Comunque se si stanno semplicemente modificando file che sono già presenti in Subversion, potrebbe non essere necessario nessuno di questi comandi finché non si fa la commit. Modifiche che si possono apportare alla propria copia di lavoro:

To make file changes, use your text editor, word processor, graphics program, or whatever tool you would normally use. Subversion handles binary files just as easily as it handles text files—and just as efficiently too.

Per apportare modifiche ad un file si può usare un editor di testi, un word processor, programmi di grafica e qualsiasi tool che si usa normalmente. Subversion gestisce i files binari con la stessa facilità con cui gestisce i file di testo— e con la stessa efficienza.

Here is an overview of the four Subversion subcommands that you'll use most often to make tree changes (we'll cover svn import and svn mkdir later).

Ecco una panoramica su 4 dei comandi di Subversion che si usano più spesso per apportare modifiche ad un albero di directory (si analizzeranno in seguito i comandi: svn import e svn mkdir).

Avvertimento

While you can edit your files with whatever tool you like, you shouldn't change the structure of your working copy without letting Subversion know what you're doing. Use the svn copy, svn delete, and svn move commands to change the structure of your working copy, and use the svn add command to place new files and directories under version control. Mentre si possono modificare i files con qualsiasi tool si desideri, non è possibile modificare la struttura della propria directory di lavoro senza dire a Subversion quello che si sta per fare. Si utilizzano i comandi svn copy, svn delete, e svn move per modificare la struttura, ed il comando svn add per collocare nuovi file e directory sotto il controllo di versione.

Once you've finished making changes, you need to commit them to the repository, but before you do so, it's usually a good idea to take a look at exactly what you've changed. By examining your changes before you commit, you can make a more accurate log message. You may also discover that you've inadvertently changed a file, and this gives you a chance to revert those changes before committing. Additionally, this is a good opportunity to review and scrutinize changes before publishing them. You can see exactly what changes you've made by using svn status, svn diff, and svn revert. You will usually use the first two commands to find out what files have changed in your working copy, and then perhaps the third to revert some (or all) of those changes.

Una volta che si è finito di apportare le modifiche, bisogna fare la commit sul repository, ma prima è una buona norma guardare con attenzione cosa si è cambiato esattamente. Esaminando le modifiche prima di effettuare la commit si può scrivere un messaggio di log più accurato. Ci si può anche rendere conto di aver modificato un file inavvertitamente e si può tornare indietro prima di fare la commit. Inoltre questa è una buona opportunità per rivedere ed analizzare le modifiche fatte prima di pubblicarle. Per vedere esattamente le modifiche apportate si possono usare i comandi svn status, svn diff e svn revert. In genere si usano i primi due comandi per vedere quali file siano stati modificati nella propria copia di lavoro, ed il terzo per annullare alcune delle modifiche effettuate (o anche tutte).

Subversion has been optimized to help you with this task, and is able to do many things without communicating with the repository. In particular, your working copy contains a secret cached “pristine” copy of each version controlled file within the .svn area. Because of this, Subversion can quickly show you how your working files have changed, or even allow you to undo your changes without contacting the repository.

Subversion è stato ottimizzato per aiutare in questo compito, e riesce a fare molte cose senza comunicare con il repository. In particolare, la propria directory di lavoro contiene una copia nascosta «originale», di ogni file sotto controllo di versione, all'interno della directory .svn. Per questo motivo, Subversion può mostrare velocemente come sono stati modificati i file di lavoro o anche permettere di annullare le modifiche senza contattare il repository.

  L     some_dir            # svn left a lock in the .svn area of some_dir
M       bar.c               # the content in bar.c has local modifications
 M      baz.c               # baz.c has property but no content modifications
X       3rd_party           # dir is part of an externals definition
?       foo.o               # svn doesn't manage foo.o
!       some_dir            # svn manages this, but it's missing or
incomplete
~       qux                 # versioned as file/dir/link, but type has
changed
I       .screenrc           # svn doesn't manage this, and is set to ignore
it
A  +    moved_dir           # added with history of where it came from
M  +    moved_dir/README    # added with history and has local modifications
D       stuff/fish.c        # file is scheduled for deletion
A       stuff/loot/bloo.h   # file is scheduled for addition
C       stuff/loot/lump.c   # file has textual conflicts from an update
 C      stuff/loot/glub.c   # file has property conflicts from an update
R       xyz.c               # file is scheduled for replacement
    S   stuff/squawk        # file or dir has been switched to a branch
     K  dog.jpg             # file is locked locally; lock-token present
     O  cat.jpg             # file is locked in the repository by other user
     B  bird.jpg            # file is locked locally, but lock has been
broken
     T  fish.jpg            # file is locked locally, but lock has been
stolen

$ svn status stuff/fish.c
D      stuff/fish.c

$ svn status --verbose
M               44        23    sally     README
                44        30    sally     INSTALL
M               44        20    harry     bar.c
                44        18    ira       stuff
                44        35    harry     stuff/trout.c
D               44        19    ira       stuff/fish.c
                44        21    sally     stuff/things
A                0         ?     ?        stuff/things/bloo.h
                44        36    harry     stuff/things/gloo.c

$ svn status --show-updates --verbose
M      *        44        23    sally     README
M               44        20    harry     bar.c
       *        44        35    harry     stuff/trout.c
D               44        19    ira       stuff/fish.c
A                0         ?     ?        stuff/things/bloo.h
Status against revision:   46

$ svn diff
Index: bar.c
===================================================================
--- bar.c	(revision 3)
+++ bar.c	(working copy)
@@ -1,7 +1,12 @@
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <unistd.h>
+
+#include <stdio.h>

 int main(void) {
-  printf("Sixty-four slices of American Cheese...\n");
+  printf("Sixty-five slices of American Cheese...\n");
 return 0;
 }

Index: README
===================================================================
--- README	(revision 3)
+++ README	(working copy)
@@ -193,3 +193,4 @@
+Note to self:  pick up laundry.

Index: stuff/fish.c
===================================================================
--- stuff/fish.c	(revision 1)
+++ stuff/fish.c	(working copy)
-Welcome to the file known as 'fish'.
-Information on fish will be here soon.

Index: stuff/things/bloo.h
===================================================================
--- stuff/things/bloo.h	(revision 8)
+++ stuff/things/bloo.h	(working copy)
+Here is a new file to describe
+things about bloo.

$ svn diff > patchfile

svn revert

Now suppose you see the above diff output, and realize that your changes to README are a mistake; perhaps you accidentally typed that text into the wrong file in your editor.

A questo punto si supponga che si siano analizzati gli output del comando diff visualizzati sopra,e si sia compreso che le modifiche apportate al file README siano un errore; forse si è accidentalmente scritto del testo nel file sbagliato.

This is a perfect opportunity to use svn revert.

È l'occasione perfetta per usare il comando svn revert.

$ svn revert README
Reverted 'README'

Subversion reverts the file to its pre-modified state by overwriting it with the cached “pristine” copy from the .svn area. But also note that svn revert can undo any scheduled operations—for example, you might decide that you don't want to add a new file after all:

Subversion riporta il file allo stato precedente alla modifica sovrascrivendo la copia «di ripristino» presente nell'area .svn. Ma si noti anche che il comando svn revert può annullare qualsiasi operazione pianificata — ad esempio, si può decidere di non voler aggiungere un nuovo file dopo tutto:

$ svn status foo
?      foo

$ svn add foo
A         foo

$ svn revert foo
Reverted 'foo'

$ svn status foo
?      foo

Nota

svn revert ITEM has exactly the same effect as deleting ITEM from your working copy and then running svn update -r BASE ITEM. However, if you're reverting a file, svn revert has one very noticeable difference—it doesn't have to communicate with the repository to restore your file. svn revert ITEM ha esattamente lo stesso effetto della cancellazione di ITEM dalla propria copia di lavoro e l'esecuzione del comando svn update -r BASE ITEM. Comunque, se si sta riportando un file allo stato precedente, il comando svn revert ha una notevole differenza — non deve comunicare con il repository per ripristinare il file.

Or perhaps you mistakenly removed a file from version control:

O forse per errore è stato rimosso un file dal controllo di versione:

$ svn status README
       README

$ svn delete README
D         README

$ svn revert README
Reverted 'README'

$ svn status README
       README

We've already seen how svn status -u can predict conflicts. Suppose you run svn update and some interesting things occur:

Si è già visto come il comando svn status -u può prevedere i conflitti. Si supponga di eseguire il comando svn update e che accada qualcosa di interessante:

$ svn update
U  INSTALL
G  README
C  bar.c
Updated to revision 46.

The U and G codes are no cause for concern; those files cleanly absorbed changes from the repository. The files marked with U contained no local changes but were Updated with changes from the repository. The G stands for merGed, which means that the file had local changes to begin with, but the changes coming from the repository didn't overlap with the local changes.

I codici di output U e G non sono utili alla causa; questi file hanno semplicemente assorbito le modifiche dal repository. I file marcati con U non contengono modifiche locali ma sono stati aggiornati con le modifiche presenti nel repository. La G indica la fusione, il che significa che il file ha modifiche locali ma che le modifiche provenienti dal repository non hanno sovrascritto quelle locali.

But the C stands for conflict. This means that the changes from the server overlapped with your own, and now you have to manually choose between them.

La C indica un conflitto. Questo vuol dire che le modifiche del server hanno sovrascritto quelle locali, ed ora bisogna scegliere manualmente tra esse.

Whenever a conflict occurs, three things typically occur to assist you in noticing and resolving that conflict:

Ogni volta che si crea un conflitto, servono tipicamente tre cose per avvisare del conflitto ed aiutare a risolverlo:

For example, Sally makes changes to the file sandwich.txt in the repository. Harry has just changed the file in his working copy and checked it in. Sally updates her working copy before checking in and she gets a conflict:

Ad esempio, Sally modifica il file sandwich.txt nel repository. Harry ha appena modificato il file nella sua copia di lavoro e ha fatto la commit. Sally ha aggiornato la sua copia di lavoro prima della propria commit ed ottiene un conflitto:

$ svn update
C  sandwich.txt
Updated to revision 2.
$ ls -1
sandwich.txt
sandwich.txt.mine
sandwich.txt.r1
sandwich.txt.r2

At this point, Subversion will not allow you to commit the file sandwich.txt until the three temporary files are removed.

A questo punto, Subversion non permetterà la commit del file sandwich.txt finché non verranno rimossi i tre files temporanei.

$ svn commit --message "Add a few more things"
svn: Commit failed (details follow):
svn: Aborting commit: '/home/sally/svn-work/sandwich.txt' remains in conflict

If you get a conflict, you need to do one of three things:

Se si ha un conflitto, è necessario fare una di queste tre cose:

Once you've resolved the conflict, you need to let Subversion know by running svn resolved. This removes the three temporary files and Subversion no longer considers the file to be in a state of conflict.^[9]

Una volta risolto il conflitto, bisogna informare Subversion eseguendo il comando svn resolved. In questo modo vengono rimossi i tre file temporanei e Subversion non considera più il file in stato di conflitto. ^[10]

$ svn resolved sandwich.txt
Resolved conflicted state of 'sandwich.txt'

$ cat sandwich.txt
Top piece of bread
Mayonnaise
Lettuce
Tomato
Provolone
<<<<<<< .mine
Salami
Mortadella
Prosciutto
=======
Sauerkraut
Grilled Chicken
>>>>>>> .r2
Creole Mustard
Bottom piece of bread

<<<<<<< .mine
Salami
Mortadella
Prosciutto
=======

=======
Sauerkraut
Grilled Chicken
>>>>>>> .r2

Top piece of bread
Mayonnaise
Lettuce
Tomato
Provolone
Salami
Mortadella
Prosciutto
Creole Mustard
Bottom piece of bread

$ svn resolved sandwich.txt
$ svn commit -m "Go ahead and use my sandwich, discarding Sally's edits."

$ svn update
C  sandwich.txt
Updated to revision 2.
$ ls sandwich.*
sandwich.txt  sandwich.txt.mine  sandwich.txt.r2  sandwich.txt.r1
$ cp sandwich.txt.r2 sandwich.txt
$ svn resolved sandwich.txt

$ svn revert sandwich.txt
Reverted 'sandwich.txt'
$ ls sandwich.*
sandwich.txt

Now you're ready to check in your changes. Note that svn resolved, unlike most of the other commands we've dealt with in this chapter, requires an argument. In any case, you want to be careful and only run svn resolved when you're certain that you've fixed the conflict in your file—once the temporary files are removed, Subversion will let you commit the file even if it still contains conflict markers.

A questo punto si è pronti per controllare le proprie modifiche. Si noti che il comando svn resolved, a differenza della maggior parte degli altri comandi che si sono visti in questo capitolo, richiede un solo argomento. In ogni caso, bisogna essere prudenti ed eseguire il comando svn resolved soltanto se si è sicuri di aver fissato i conflitti nel proprio file — una volta che i file temporanei sono stati rimossi, Subversion permette di eseguire la commit del file anche se contiene ancora marcatori di conflitto.

Finally! Your edits are finished, you've merged all changes from the server, and you're ready to commit your changes to the repository.

Finalmente! Le modifiche sono finite, sono stati presi tutti i cambiamenti dal server e si è pronti ad eseguire la commit delle modifiche fatte sul repository.

The svn commit command sends all of your changes to the repository. When you commit a change, you need to supply a log message, describing your change. Your log message will be attached to the new revision you create. If your log message is brief, you may wish to supply it on the command line using the --message (or -m) option:

Il comando svn commit invia tutte le modifiche al repository. Quando si fa la commit di una modifica bisogna aggiungere un messaggio di log , che descriva il cambiamento. Il messaggio di log sarà allegato alla nuova revisione appena creata. Se il messaggio di log è breve, è possibile aggiungerlo da riga di comando usando l'opzione --message (o -m):

$ svn commit --message "Corrected number of cheese slices."
Sending        sandwich.txt
Transmitting file data .
Committed revision 3.

However, if you've been composing your log message as you work, you may want to tell Subversion to get the message from a file by passing the filename with the --file switch:

Comunque, se si è composto il messaggio di log durante il lavoro, è possibile comunicare a Subversion di prendere il messaggio da file passandogli il nome del file con l'opzione --file:

$ svn commit --file logmsg
Sending        sandwich.txt
Transmitting file data .
Committed revision 4.

If you fail to specify either the --message or --file switch, then Subversion will automatically launch your favorite editor (see the editor-cmd section in sezione chiamata «Config») for composing a log message.

Se ci si dimentica di specificare una delle due opzioni --message o --file, Subversion lancia automaticamente il proprio editor preferito (si veda la sezione editor-cmd in sezione chiamata «Config») per comporre un messaggio di log.

Suggerimento

If you're in your editor writing a commit message and decide that you want to cancel your commit, you can just quit your editor without saving changes. If you've already saved your commit message, simply delete the text and save again. Se si sta compilando con il proprio editor un messaggio di commit e si decide di annullare la commit, basta chiudere l'editor senza salvare le modifiche. Se si è già salvato il messaggio di commit, basta cancellare il testo e salvare di nuovo. $ svn commit Waiting for Emacs...Done Log message unchanged or not specified a)bort, c)ontinue, e)dit a $

The repository doesn't know or care if your changes make any sense as a whole; it only checks to make sure that nobody else has changed any of the same files that you did when you weren't looking. If somebody has done that, the entire commit will fail with a message informing you that one or more of your files is out-of-date:

Il repository non sa e non è interessato al fatto che le modifiche apportate abbiano un senso; si assicura soltanto che nessun altro abbia modificato qualcosa degli stessi file senza accorgersene. Se qualcuno l'ha fatto l'intero commit fallirà e un messaggio informerà che uno o più file non sono aggiornati:

$ svn commit --message "Add another rule"
Sending        rules.txt
svn: Commit failed (details follow):
svn: Out of date: 'rules.txt' in transaction 'g'

At this point, you need to run svn update, deal with any merges or conflicts that result, and attempt your commit again.

A questo punto bisogna eseguire il comando svn update, gestire conflitti e fusioni risultanti ed eseguire la commit di nuovo.

That covers the basic work cycle for using Subversion. There are many other features in Subversion that you can use to manage your repository and working copy, but you can get by quite easily using only the commands that we've discussed so far in this chapter.

Questo conclude il ciclo base di lavoro per usare Subversion. Ci sono molte altre caratteristiche in Subversion che possono essere usate per gestire il repository e la copia di lavoro, ma si può procedere facilmente usando solo i comandi che sono stati discussi in precedenza in questo capitolo.

To find information about the history of a file or directory, use the svn log command. svn log will provide you with a record of who made changes to a file or directory, at what revision it changed, the time and date of that revision, and, if it was provided, the log message that accompanied the commit.

Per trovare informazioni sulla storia di un file o una directory, si usa il comando svn log. svn log fornirà una registrazione di chi ha fatto modifiche ad un file o una directory, a quale revisione è stato modificato, l'ora e il giorno della revisione, e, se previsto, il messaggio di log che ha accompagnato la commit.

$ svn log
------------------------------------------------------------------------
r3 | sally | Mon, 15 Jul 2002 18:03:46 -0500 | 1 line

Added include lines and corrected # of cheese slices.
------------------------------------------------------------------------
r2 | harry | Mon, 15 Jul 2002 17:47:57 -0500 | 1 line

Added main() methods.
------------------------------------------------------------------------
r1 | sally | Mon, 15 Jul 2002 17:40:08 -0500 | 1 line

Initial import
------------------------------------------------------------------------

Note that the log messages are printed in reverse chronological order by default. If you wish to see a different range of revisions in a particular order, or just a single revision, pass the --revision (-r) switch:

Si noti che i messaggi di log sono stampati predefinitamente in ordine cronologico inverso. Se si desidera vedere un differente intrevallo di revisioni in un ordine particolare, o solo una singola revisione, bisogna usare l'opzione --revision (-r):

$ svn log --revision 5:19    # shows logs 5 through 19 in chronological order

$ svn log -r 19:5            # shows logs 5 through 19 in reverse order

$ svn log -r 8               # shows log for revision 8

You can also examine the log history of a single file or directory. For example:

Si può esaminare la storia dei log di un singolo file o directory. Ad esempio:

$ svn log foo.c
…
$ svn log http://foo.com/svn/trunk/code/foo.c
…

These will display log messages only for those revisions in which the working file (or URL) changed.

Sarà mostrato solo il log di quelle revisioni in cui il file di lavoro (o URL) è cambiato.

If you want even more information about a file or directory, svn log also takes a --verbose (-v) switch. Because Subversion allows you to move and copy files and directories, it is important to be able to track path changes in the filesystem, so in verbose mode, svn log will include a list of changed paths in a revision in its output:

Se si vogliono maggiori informazioni su un file o una directory, svn log possiede anche l'opzione --verbose (-v). Poiché Subversion permette di spostare e copiare file e directory, è importante riuscire a tener traccia dei cambiamenti di percorso nel filesystem, così in modalità verbose, svn log nel suo output includerà una lista dei percorsi modificati in una revisione :

$ svn log -r 8 -v
------------------------------------------------------------------------
r8 | sally | 2002-07-14 08:15:29 -0500 | 1 line
Changed paths:
M /trunk/code/foo.c
M /trunk/code/bar.h
A /trunk/code/doc/README

Frozzled the sub-space winch.

------------------------------------------------------------------------

svn log also takes a --quiet (-q) switch, which suppresses the body of the log message. When combined with --verbose, it gives just the names of the changed files.

svn log possiede anche un'opzione --quiet (-q), che sopprime il corpo del messaggio di log. Quando è combinata con l'opzione --verbose, essa fornisce solo i nomi dei files modificati.

$ svn log -r 2
------------------------------------------------------------------------
$

We've already seen svn diff before—it displays file differences in unified diff format; it was used to show the local modifications made to our working copy before committing to the repository.

Si è gia visto svn diff precedentemente — mostra le modifiche di un file in un formato unificato diff; è stato usato per mostrare le modifiche locali fatte nella propria copia di lavoro prima di fare la commit al repository.

In fact, it turns out that there are three distinct uses of svn diff:

Infatti, si vede che ci sono tre usi distinti del comandosvn diff:

$ svn diff
Index: rules.txt
===================================================================
--- rules.txt	(revision 3)
+++ rules.txt	(working copy)
@@ -1,4 +1,5 @@
 Be kind to others
 Freedom = Responsibility
 Everything in moderation
-Chew with your mouth open
+Chew with your mouth closed
+Listen when others are speaking
$

$ svn diff --revision 3 rules.txt
Index: rules.txt
===================================================================
--- rules.txt	(revision 3)
+++ rules.txt	(working copy)
@@ -1,4 +1,5 @@
 Be kind to others
 Freedom = Responsibility
 Everything in moderation
-Chew with your mouth open
+Chew with your mouth closed
+Listen when others are speaking
$

$ svn diff --revision 2:3 rules.txt
Index: rules.txt
===================================================================
--- rules.txt	(revision 2)
+++ rules.txt	(revision 3)
@@ -1,4 +1,4 @@
 Be kind to others
-Freedom = Chocolate Ice Cream
+Freedom = Responsibility
 Everything in moderation
 Chew with your mouth open
$

$ svn diff --revision 4:5 http://svn.red-bean.com/repos/example/trunk/text/rules.txt
…
$

If you want to examine an earlier version of a file and not necessarily the differences between two files, you can use svn cat:

Se si vuole esaminare una versione precedente di un file e non necessariamente le differenze tra due file, si può usare il comando svn cat:

$ svn cat --revision 2 rules.txt
Be kind to others
Freedom = Chocolate Ice Cream
Everything in moderation
Chew with your mouth open
$

You can also redirect the output directly into a file:

Si può redirezionare l'output direttamente in un file:

$ svn cat --revision 2 rules.txt > rules.txt.v2
$

You're probably wondering why we don't just use svn update --revision to update the file to the older revision. There are a few reasons why we might prefer to use svn cat.

Probabilmente ci si meraviglierà del fatto che non si usa solo il comando svn update --revision per aggiornare il file ad una versione precedente. Ci sono diverse ragioni per preferire il comando svn cat.

First, you may want to see the differences between two revisions of a file using an external diff program (perhaps a graphical one, or perhaps your file is in such a format that the output of unified diff is nonsensical). In this case, you'll need to grab a copy of the old revision, redirect it to a file, and pass both that and the file in your working copy to your external diff program.

Come prima cosa, si possono voler vedere le differenze tra due revisioni di un file usando un programma diff esterno (magari uno grafico, o magari il file è in un formato tale che l'output in formato unificato diff non avrebbe senso). In questo caso, bisogna prendere una copia della revisione precedente, redirezionarla su un file, e passare sia quella sia il file nella propria copia di lavoro al programma diff esterno.

Sometimes it's easier to look at an older version of a file in its entirety as opposed to just the differences between it and another revision.

A volte è più facile guardare una versione precedente di un file per intero che analizzare solo le differenze tra quella ed un'altra revisione.

The svn list command shows you what files are in a repository directory without actually downloading the files to your local machine:

Il comando svn list mostra quali file sono nel repository senza attualmente scaricarli nalla propria macchina:

$ svn list http://svn.collab.net/repos/svn
README
branches/
clients/
tags/
trunk/

If you want a more detailed listing, pass the --verbose (-v) flag to get output like this:

Se si vuole una lista più dettagliata, si deve usrae l'opzione --verbose (-v) per avere un output come questo:

$ svn list --verbose http://svn.collab.net/repos/svn
   2755 harry          1331 Jul 28 02:07 README
   2773 sally               Jul 29 15:07 branches/
   2769 sally               Jul 29 12:07 clients/
   2698 harry               Jul 24 18:07 tags/
   2785 sally               Jul 29 19:07 trunk/

The columns tell you the revision at which the file or directory was last modified, the user who modified it, the size if it is a file, the date it was last modified, and the item's name.

Le colonne indicano la revisione nella quale il file o la directory è stato modificato l'ultima volta, l'utente che ha eseguito le modifiche, la dimensione se si tratta di un file, la data dell'ultima modifica, e il nome dell'oggetto.

In addition to all of the above commands, you can use svn update and svn checkout with the --revision switch to take an entire working copy “back in time” ^[13]:

In aggiunta a tutti i comandi visti sopra, si possono usare i comandi svn update e svn checkout con l'opzione --revision per portare un'intera copia di lavoro «indietro nel tempo» ^[14]:

$ svn checkout --revision 1729 # Checks out a new working copy at r1729
…
$ svn update --revision 1729 # Updates an existing working copy to r1729
…

When Subversion modifies your working copy (or any information within .svn), it tries to do so as safely as possible. Before changing the working copy, Subversion writes its intentions to a log file. Next it executes the commands in the log file to apply the requested change, holding a lock on the relevant part of the working copy while it works — to prevent othe Subversion clients from accessing the working copy in mid-change. Finally, Subversion removes the log file. Architecturally, this is similar to a journaled filesystem. If a Subversion operation is interrupted (if the process is killed, or if the machine crashes, for example), the log files remain on disk. By re-executing the log files, Subversion can complete the previously started operation, and your working copy can get itself back into a consistent state.

Quando Subversion modifica la propria copia di lavoro (o qualsiasi informazione all'intreno di .svn), cerca di farlo nel modo più sicuro possibile. Prima di modificare la copia di lavoro, Subversion scrive le sue intenzioni in un file di log. Dopo esegue i comandi nel file di log per applicare le modifiche richieste, mettendo un blocco sulla parte importante della copia di lavoro mentre è in funzione — per impedire ad altri client Subversion l'accesso alla copia di lavoro durante la modifica. Infine, Subversion rimuove il file log. Architetturalmente, è simile ad un filesystem con journaling. Se un'operazione di Subversion viene interrotta (per esmpio, se il processo viene terminato, o se la macchina va incrash), i files di log restano sul disco. Rieseguendo i file di log Subversion può completare le operazioni iniziate prima, e la copia di lavoro può tornare in un stato consistente.

And this is exactly what svn cleanup does: it searches your working copy and runs any leftover logs, removing working copy locks in the process. If Subversion ever tells you that some part of your working copy is “locked”, then this is the command that you should run. Also, svn status will display an L next to locked items:

E questo è esattamente quello che fa il comando svn cleanup: cerca la copia di lavoro e esegue tutti i log rimasti in sospeso, rimuovendo i blocchi alla copia di lavoro nel processo. Se Subversion comunica che alcune parti della copia di lavoro sono «bloccate», allora questo è il comando da eseguire. Inoltre, il comando svn status visualizzerà una L vicino agli oggetti bloccati:

$ svn status
  L    somedir
M      somedir/foo.c

$ svn cleanup
$ svn status
M      somedir/foo.c

Don't confuse these working copy locks with the ordinary locks that Subversion users create when using the “lock-modify-unlock” model of concurrent version control; see Three meanings of «lock» for clarification.

Non si confondano questi blocchi alla copia di lavoro con i blocchi ordinari che gli utenti di Subversion creano quando usano il modello di controllo di versione concorrente «blocco-modifica-sblocco»; si veda Three meanings of «lock» per chiarimenti.

The svn import command is a quick way to copy an unversioned tree of files into a repository, creating intermediate directories as necessary.

Il comando svn import è un modo veloce per copiare un albero di file non sotto il controllo di versione in un repository, creando se necessario directory intermedie.

$ svnadmin create /usr/local/svn/newrepos
$ svn import mytree file:///usr/local/svn/newrepos/some/project \
             -m "Initial import"
Adding         mytree/foo.c
Adding         mytree/bar.c
Adding         mytree/subdir
Adding         mytree/subdir/quux.h

Committed revision 1.

The previous example copied the contents of directory mytree under the directory some/project in the repository:

Il precedente esempio ha copiato il contenuto della directory mytree sotto la directory some/project nel repository:

$ svn list file:///usr/local/svn/newrepos/some/project
bar.c
foo.c
subdir/

Note that after the import is finished, the original tree is not converted into a working copy. To start working, you still need to svn checkout a fresh working copy of the tree.

Si noti che una volta finita l'importazione, l'albero originale non è convertito in una copia di lavoro. Per cominciare a lavorare, bisogna usare il comandosvn checkout per avere una copia di lavoro dell'albero.

Creating a branch is very simple—you make a copy of the project in the repository using the svn copy command. Subversion is not only able to copy single files, but whole directories as well. In this case, you want to make a copy of the /calc/trunk directory. Where should the new copy live? Wherever you wish—it's a matter of project policy. Let's say that your team has a policy of creating branches in the /calc/branches area of the repository, and you want to name your branch my-calc-branch. You'll want to create a new directory, /calc/branches/my-calc-branch, which begins its life as a copy of /calc/trunk.

Creare un ramo è molto semplice—fatte una copia di progetto in deposito(repository) usando il comando svn copy. Subversion è capace non solo di copiare i singoli file, ma anche intere cartelle. Nel nostro caso, volete fare una copia della cartella /calc/trunk. Dove la mettiamo? Dovunque desideriate—è un aspetto di regole del progetto. Diciamo che il vostro gruppo ha stabilito la regola di creare rami nella area del deposito(repository) /calc/branches, e voi volete chiamare vostro ramo my-calc-branch. State per creare nuova cartella, /calc/branches/my-calc-branch, che nasce come copia di /calc/trunk.

There are two different ways to make a copy. We'll demonstrate the messy way first, just to make the concept clear. To begin, check out a working copy of the project's root directory, /calc:

Ci sono due modi diversi di fare una copia. Vi dimostriamo prima quello ingarbugliato, solo per fare chiaro il concetto. Per cominciare, tiriamo fuori una copia di lavoro della cartella principale del progetto, /calc:

$ svn checkout http://svn.example.com/repos/calc bigwc
A  bigwc/trunk/
A  bigwc/trunk/Makefile
A  bigwc/trunk/integer.c
A  bigwc/trunk/button.c
A  bigwc/branches/
Checked out revision 340.

Making a copy is now simply a matter of passing two working-copy paths to the svn copy command:

Creare una copia è adesso semplice questione di passare due percorsi di copia di lavoro al comando svn copy:

$ cd bigwc
$ svn copy trunk branches/my-calc-branch
$ svn status
A  +   branches/my-calc-branch

In this case, the svn copy command recursively copies the trunk working directory to a new working directory, branches/my-calc-branch. As you can see from the svn status command, the new directory is now scheduled for addition to the repository. But also notice the “+” sign next to the letter A. This indicates that the scheduled addition is a copy of something, not something new. When you commit your changes, Subversion will create /calc/branches/my-calc-branch in the repository by copying /calc/trunk, rather than resending all of the working copy data over the network:

In questo caso, il comando svn copy copia ricorsivamente cartella di lavoro trunk nella nuova cartella di lavoro, branches/my-calc-branch. Come si può vedere dal comando svn status, la nuova cartella è adesso pianificata per essere aggiunta al deposito(repository). Notare anche il segno «+» vicino la lettera A. Questo indica che la aggiunta pianificata è una copia di qualcosa, non qualcosa di nuovo. Quando pubblicate i vostri cambiamenti, Subversion creerà /calc/branches/my-calc-branch nel deposito(repository) copiando /calc/trunk, invece di re-inviare tramite la rete tutti i dati dalla cartella di lavoro:

$ svn commit -m "Creating a private branch of /calc/trunk."
Adding         branches/my-calc-branch
Committed revision 341.

$ svn commit -m "Creato un ramo privato da /calc/trunk."
Adding         branches/my-calc-branch
Committed revision 341.

And now the easier method of creating a branch, which we should have told you about in the first place: svn copy is able to operate directly on two URLs.

E adesso il metodo più semplice di creare un ramo, di cui si doveva parlare per primo: svn copy può operare direttamente su due URL.

$ svn copy http://svn.example.com/repos/calc/trunk \
           http://svn.example.com/repos/calc/branches/my-calc-branch \
      -m "Creating a private branch of /calc/trunk."

Committed revision 341.

  $ svn copy http://svn.example.com/repos/calc/trunk \
  http://svn.example.com/repos/calc/branches/my-calc-branch \
  -m "Creato un ramo privato da /calc/trunk."

  Committed revision 341.

There's really no difference between these two methods. Both procedures create a new directory in revision 341, and the new directory is a copy of /calc/trunk. This is shown in Figura 4.3, «Deposito con la nuova copia». Notice that the second method, however, performs an immediate commit. ^[15] It's an easier procedure, because it doesn't require you to check out a large mirror of the repository. In fact, this technique doesn't even require you to have a working copy at all.

Realmente non c'è differenza tra questi due metodi. Entrambe le procedure creano una nuova cartella nella revisione 341 e la nuova cartella è una copia di /calc/trunk. Come mostrato nella Figura 4.3, «Deposito con la nuova copia». Notare che il secondo metodo, tuttavia, fa anche commit immediato. ^[16] Questa è una procedura più semplice, perché non richiede di fare checkout di grande parte del deposito(repository). Infatti, questa tecnica addirittura non richiede neanche di avere una copia di lavoro.

Figura 4.3. Deposito con la nuova copia

Now that you've created a branch of the project, you can check out a new working copy to start using it:

Adesso che avete creato un ramo del progetto, potete tirare fuori (check out) una nuova copia di lavoro per cominciar ad usarla:

$ svn checkout http://svn.example.com/repos/calc/branches/my-calc-branch
A  my-calc-branch/Makefile
A  my-calc-branch/integer.c
A  my-calc-branch/button.c
Checked out revision 341.

There's nothing special about this working copy; it simply mirrors a different directory in the repository. When you commit changes, however, Sally won't ever see them when she updates. Her working copy is of /calc/trunk. (Be sure to read sezione chiamata «Cambiare una copia di lavoro» later in this chapter: the svn switch command is an alternate way of creating a working copy of a branch.)

Non c'è niente speciale di questa copia di lavoro; semplicemente rispecchia una cartella diversa del deposito(repository). Quando pubblicate le vostre modifiche (commit), tuttavia, Sally non può nenche vederle quando fa aggiornamento (update). La sua copia di lavoro è di /calc/trunk. (Assicuratevi di leggere la sezione chiamata «Cambiare una copia di lavoro» più avanti in questo capitolo: il comando svn switch è un modo alternativo di creare copia di lavoro di un ramo.)

Let's pretend that a week goes by, and the following commits happen:

Facciamo finta che le settimane passano e succedono sequenti pubblicazioni (commit):

There are now two independent lines of development, shown in Figura 4.4, «Ramificazione della storia d'un file», happening on integer.c.

Ci sono adesso due linee di sviluppo independenti, mostrate nella Figura 4.4, «Ramificazione della storia d'un file», che toccano integer.c.

Figura 4.4. Ramificazione della storia d'un file

Things get interesting when you look at the history of changes made to your copy of integer.c:

Le cose diventano interessanti quando guardate la storia delle modifiche della vostra copia di integer.c:

$ pwd
/home/user/my-calc-branch

$ svn log --verbose integer.c
------------------------------------------------------------------------
r343 | user | 2002-11-07 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines
Changed paths:
   M /calc/branches/my-calc-branch/integer.c

* integer.c:  frozzled the wazjub.

------------------------------------------------------------------------
r341 | user | 2002-11-03 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines
Changed paths:
   A /calc/branches/my-calc-branch (from /calc/trunk:340)

Creating a private branch of /calc/trunk.

------------------------------------------------------------------------
r303 | sally | 2002-10-29 21:14:35 -0600 (Tue, 29 Oct 2002) | 2 lines
Changed paths:
   M /calc/trunk/integer.c

* integer.c:  changed a docstring.

------------------------------------------------------------------------
r98 | sally | 2002-02-22 15:35:29 -0600 (Fri, 22 Feb 2002) | 2 lines
Changed paths:
   M /calc/trunk/integer.c

* integer.c:  adding this file to the project.

------------------------------------------------------------------------

  $ pwd
  /home/user/my-calc-branch

  $ svn log --verbose integer.c
  ------------------------------------------------------------------------
  r343 | user | 2002-11-07 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines
  Changed paths:
  M /calc/branches/my-calc-branch/integer.c

  * integer.c:  frozzled the wazjub.

  ------------------------------------------------------------------------
  r341 | user | 2002-11-03 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines
  Changed paths:
  A /calc/branches/my-calc-branch (from /calc/trunk:340)

  Creato un ramo privato da /calc/trunk

  ------------------------------------------------------------------------
  r303 | sally | 2002-10-29 21:14:35 -0600 (Tue, 29 Oct 2002) | 2 lines
  Changed paths:
  M /calc/trunk/integer.c

  * integer.c:  cambiato un docstring.

  ------------------------------------------------------------------------
  r98 | sally | 2002-02-22 15:35:29 -0600 (Fri, 22 Feb 2002) | 2 lines
  Changed paths:
  M /calc/trunk/integer.c

  * integer.c:  aggiunto questo file al progetto.

  ------------------------------------------------------------------------

Notice that Subversion is tracing the history of your branch's integer.c all the way back through time, even traversing the point where it was copied. It shows the creation of the branch as an event in the history, because integer.c was implicitly copied when all of /calc/trunk/ was copied. Now look what happens when Sally runs the same command on her copy of the file:

Notare che Subversion tiene traccia della storia di integer.c del vostro ramo dietro tutto il tempo, attraversando anche il punto dov'è stato copiato. Mostra la creazione del ramo come evento nella storia, perché integer.c era stato implicitamente copiato quando tutto il /calc/trunk/ era stato copiato. Adesso guardate che sucede quando Sally avvia lo stesso comando sulla sua copia del file:

  $ pwd
  /home/sally/calc

  $ svn log --verbose integer.c
  ------------------------------------------------------------------------
  r344 | sally | 2002-11-07 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines
  Changed paths:
  M /calc/trunk/integer.c

  * integer.c:  fix a bunch of spelling errors.

  ------------------------------------------------------------------------
  r303 | sally | 2002-10-29 21:14:35 -0600 (Tue, 29 Oct 2002) | 2 lines
  Changed paths:
  M /calc/trunk/integer.c

  * integer.c:  changed a docstring.

  ------------------------------------------------------------------------
  r98 | sally | 2002-02-22 15:35:29 -0600 (Fri, 22 Feb 2002) | 2 lines
  Changed paths:
  M /calc/trunk/integer.c

  * integer.c:  adding this file to the project.

  ------------------------------------------------------------------------

  $ pwd
  /home/sally/calc

  $ svn log --verbose integer.c
  ------------------------------------------------------------------------
  r344 | sally | 2002-11-07 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines
  Changed paths:
  M /calc/trunk/integer.c

  * integer.c:  riparata una manciata di errori ortografici.

  ------------------------------------------------------------------------
  r303 | sally | 2002-10-29 21:14:35 -0600 (Tue, 29 Oct 2002) | 2 lines
  Changed paths:
  M /calc/trunk/integer.c

  * integer.c:  cambiato un docstring.

  ------------------------------------------------------------------------
  r98 | sally | 2002-02-22 15:35:29 -0600 (Fri, 22 Feb 2002) | 2 lines
  Changed paths:
  M /calc/trunk/integer.c

  * integer.c:  aggiunto questo file al progetto.

  ------------------------------------------------------------------------

Sally sees her own revision 344 change, but not the change you made in revision 343. As far as Subversion is concerned, these two commits affected different files in different repository locations. However, Subversion does show that the two files share a common history. Before the branch-copy was made in revision 341, they used to be the same file. That's why you and Sally both see the changes made in revisions 303 and 98.

Sally vede la sua modifica nella versione 344, ma non la modifica che voi avete fatto nella versione 343. Per quel che riguarda Subversion, questi due commit riguardano i file diversi nelle diverse locazioni del deposito(repository). Tuttavia, Subversion mostra che questi due file condividono una storia comune. Prima che era fatta copia del ramo nella versione 341, essi erano l'unico file. E per questo entrambi, voi e Sally, vedete le modifiche fatte nelle versioni 303 e 98.

There are two important lessons that you should remember from this section.

Ci sono due lezioni importanti che dovete ricordare da questa sezione.

In the previous section, we mentioned that both you and Sally made changes to integer.c on different branches. If you look at Sally's log message for revision 344, you can see that she fixed some spelling errors. No doubt, your copy of the same file still has the same spelling errors. It's likely that your future changes to this file will be affecting the same areas that have the spelling errors, so you're in for some potential conflicts when you merge your branch someday. It's better, then, to receive Sally's change now, before you start working too heavily in the same places.

Nella precedente sezione, abbiamo menzionato che entrambi, voi e Sally avete fatto modifiche su integer.c nei rami diversi. Se date un sguardo al messaggio di log di Sally (versione 344), potete vedere che ella ha corretto qualche errore di battitura. Senza dubbio, vostra copia dello stesso file ancora ha gli stessi errori. È probabile che le vostre future modifiche al file toccheranno gli stessi posti che hanno errori di battitura, così sorgeranno alcuni potenziali conflitti, quando un giorno andrete a fondere il vostro ramo. Meglio incorporare le modifiche di Sally adesso, prima che cominciate lavoro troppo pesante sugli stessi posti.

It's time to use the svn merge command. This command, it turns out, is a very close cousin to the svn diff command (which you read about in Chapter 3). Both commands are able to compare any two objects in the repository and describe the differences. For example, you can ask svn diff to show you the exact change made by Sally in revision 344:

È ora di usare comando svn merge. Questo comando, come si vedrà, è cugino molto stretto del comando svn diff (di quale avete letto nel Capitolo 3). Entrambi comandi sono capaci di comparare qualsiasi due oggetti in deposito(repository) e descrivere le differenze. Per esempio, potete chiedere a svn diff di mostrare esatta modifica fatta da Sally nella versione 344:

$ svn diff -r 343:344 http://svn.example.com/repos/calc/trunk

Index: integer.c
===================================================================
--- integer.c   (revision 343)
+++ integer.c   (revision 344)
@@ -147,7 +147,7 @@
     case 6:  sprintf(info->operating_system, "HPFS (OS/2 or NT)"); break;
     case 7:  sprintf(info->operating_system, "Macintosh"); break;
     case 8:  sprintf(info->operating_system, "Z-System"); break;
-    case 9:  sprintf(info->operating_system, "CPM"); break;
+    case 9:  sprintf(info->operating_system, "CP/M"); break;
     case 10:  sprintf(info->operating_system, "TOPS-20"); break;
     case 11:  sprintf(info->operating_system, "NTFS (Windows NT)"); break;
     case 12:  sprintf(info->operating_system, "QDOS"); break;
@@ -164,7 +164,7 @@
     low = (unsigned short) read_byte(gzfile);  /* read LSB */
     high = (unsigned short) read_byte(gzfile); /* read MSB */
     high = high << 8;  /* interpret MSB correctly */
-    total = low + high; /* add them togethe for correct total */
+    total = low + high; /* add them together for correct total */

     info->extra_header = (unsigned char *) my_malloc(total);
     fread(info->extra_header, total, 1, gzfile);
@@ -241,7 +241,7 @@
      Store the offset with ftell() ! */

   if ((info->data_offset = ftell(gzfile))== -1) {
-    printf("error: ftell() retturned -1.\n");
+    printf("error: ftell() returned -1.\n");
     exit(1);
   }

@@ -249,7 +249,7 @@
   printf("I believe start of compressed data is %u\n", info->data_offset);
   #endif

-  /* Set postion eight bytes from the end of the file. */
+  /* Set position eight bytes from the end of the file. */

   if (fseek(gzfile, -8, SEEK_END)) {
     printf("error: fseek() returned non-zero\n");

  $ svn diff -r 343:344 http://svn.example.com/repos/calc/trunk

  Index: integer.c
  ===================================================================
  --- integer.c   (revision 343)
  +++ integer.c   (revision 344)
  @@ -147,7 +147,7 @@
  case 6:  sprintf(info->operating_system, "HPFS (OS/2 or NT)"); break;
  case 7:  sprintf(info->operating_system, "Macintosh"); break;
  case 8:  sprintf(info->operating_system, "Z-System"); break;
  -    case 9:  sprintf(info->operating_system, "CPM"); break;
  +    case 9:  sprintf(info->operating_system, "CP/M"); break;
  case 10:  sprintf(info->operating_system, "TOPS-20"); break;
  case 11:  sprintf(info->operating_system, "NTFS (Windows NT)"); break;
  case 12:  sprintf(info->operating_system, "QDOS"); break;
  @@ -164,7 +164,7 @@
  low = (unsigned short) read_byte(gzfile);  /* read LSB */
  high = (unsigned short) read_byte(gzfile); /* read MSB */
  high = high << 8;  /* interpreta MSB correttamente */
  -    total = low + high; /* sommali inseme per un totale corretto */
  +    total = low + high; /* sommali insieme per un totale corretto */

  info->extra_header = (unsigned char *) my_malloc(total);
  fread(info->extra_header, total, 1, gzfile);
  @@ -241,7 +241,7 @@
  Memorizza offset con ftell() ! */

  if ((info->data_offset = ftell(gzfile))== -1) {
  -    printf("errore: ftell() ha resttituito -1.\n");
  +    printf("errore: ftell() ha restituito -1.\n");
  exit(1);
  }

  @@ -249,7 +249,7 @@
  printf("Credo che inizio dei dati compressi è %u\n", info->data_offset);
  #endif

  -  /* Imposta poszione otto byte dalla fine del file. */
  +  /* Imposta posizione otto byte dalla fine del file. */

  if (fseek(gzfile, -8, SEEK_END)) {
  printf("errore: fseek() ha restituito non-zero\n");

The svn merge command is almost exactly the same. Instead of printing the differences to your terminal, however, it applies them directly to your working copy as local modifications:

Il comando svn merge è quasi esattamente uguale. Invece di mostrare le differenze sullo schermo, tuttavia, le applica direttamente nella vostra copia di lavoro come modifiche locali:

$ svn merge -r 343:344 http://svn.example.com/repos/calc/trunk
U  integer.c

$ svn status
M  integer.c

The output of svn merge shows that your copy of integer.c was patched. It now contains Sally's change—the change has been “copied” from the trunk to your working copy of your private branch, and now exists as a local modification. At this point, it's up to you to review the local modification and make sure it works correctly.

L'output di svn merge mostra che vostra copia di integer.c era stata modificata. Adesso contiene le modifiche di Sally—le modifiche erano state «copiate» dal tronco nella copia di lavoro del vostro ramo privato e adesso esistono come modifiche locali. A questo punto, tocca a voi rivedere le modifiche locali ed assicurare che funzionano correttamente.

In another scenario, it's possible that things may not have gone so well, and that integer.c may have entered a conflicted state. You might need to resolve the conflict using standard procedures (see Chapter 3), or if you decide that the merge was a bad idea altogether, simply give up and svn revert the local change.

In un altro scenario, è possibile che le cose possono non andare così bene e perciò integer.c può entrare nello stato di conflitto. Potette avere bisogno di risolvere il conflitto usando procedure standard (vedi Capitolo 3), oppure se decidete che fusione era del tutto una cativa idea, semplicemente passare sopra e scartare con svn revert le modifiche locali.

But assuming that you've reviewed the merged change, you can svn commit the change as usual. At that point, the change has been merged into your repository branch. In version control terminology, this act of copying changes between branches is commonly called porting changes.

Ma assumendo che avete ispezionato le modifiche incorporate, potete pubblicarle con svn commit come al solito. A questo punto, la modifica sarà fusa dentro il vostro ramo del deposito(repository). Nella terminologia di controlo delle versioni, questo atto di copiatura delle modifiche tra i rami è comunemnte chaimato porting dele modifiche.

When you commit the local modification, make sure your log message mentions that you're porting a specific change from one branch to another. For example:

Facendo commit delle modifiche locali, assicuratevi che vostro messaggio menziona che state portando una modifica specifica da un ramo ad altro. Per esempio:

$ svn commit -m "integer.c: ported r344 (spelling fixes) from trunk."
Sending        integer.c
Transmitting file data .
Committed revision 360.

  $ svn commit -m "integer.c: portata r344 (fix di ortografia) dal tronco."
  Sending        integer.c
  Transmitting file data .
  Committed revision 360.

As you'll see in the next sections, this is a very important “best practice” to follow.

Come vedrete nella prossima sezione, questa è molto importante «regola d'arte» da seguire.

$ svn diff -r 343:344 http://svn.example.com/repos/calc/trunk > patchfile
$ patch -p0  < patchfile
Patching file integer.c using Plan A...
Hunk #1 succeeded at 147.
Hunk #2 succeeded at 164.
Hunk #3 succeeded at 241.
Hunk #4 succeeded at 249.
done

A word of warning: while svn diff and svn merge are very similar in concept, they do have different syntax in many cases. Be sure to read about them in Chapter 9 for details, or ask svn help. For example, svn merge requires a working-copy path as a target, i.e. a place where it should apply the tree-changes. If the target isn't specified, it assumes you are trying to perform one of the following common operations:

Una parola di avvertimento: anche se svn diff e svn merge sono nel concetto molto simili, hanno in molti casi la sintassi diversa. Assicuratevi di leggere dettagli nel Capitolo 9 o chiedete lumi a svn help. Per esempio, svn merge richiede percorso di copia di lavoro come destinazione, i.e. un posto dove può applicare le modifiche della struttura. Se la destinazione non è specificata, assume che state provando di fare una delle seguenti comuni operazioni:

If you are merging a directory and haven't specified a target path, svn merge assumes the first case above and tries to apply the changes into your current directory. If you are merging a file, and that file (or a file by the same name) exists in your current working directory, svn merge assumes the second case and tries to apply the changes to a local file with the same name.

Se state fondendo una cartella e non avete specificato percorso di destinazione, svn merge assume il primo caso sopra e prova applicare le modifiche dentro vostra cartella attuale. Se state fondendo un file e questo file (o un file con lo stesso nome) esiste dentro vostra cartella attuale, svn merge assume il secondo caso e prova applicare le modifiche dentro file locale con lo stesso nome.

If you want changes applied somewhere else, you'll need to say so. For example, if you're sitting in the parent directory of your working copy, you'll have to specify the target directory to receive the changes:

Se volete applicare le modifiche in un altro posto, dovete dirlo. Per esempio, se siete nella cartella parente della vostra copia di lavoro, dovete specificare cartella destinazione per ricevere le modifiche:

$ svn merge -r 343:344 http://svn.example.com/repos/calc/trunk my-calc-branch
U   my-calc-branch/integer.c

You've now seen an example of the svn merge command, and you're about to see several more. If you're feeling confused about exactly how merging works, you're not alone. Many users (especially those new to version control) are initially perplexed about the proper syntax of the command, and about how and when the feature should be used. But fear not, this command is actually much simpler than you think! There's a very easy technique for understanding exactly how svn merge behaves.

Abbiamo visto un esempio di comando svn merge, e stiamo per vedere di più. Se vi sentite confusi riguardo come funziona esattamente la fusione, non siete soli. Molti utenti (specialmente quelli nuovi a cotrollo delle versioni) rimangono inizialmente perplessi riguardo la giusta sintassi del comando e come e quando usare questa caratteristica. Non avere paura, questo comando è in verità molto più semplice che si pensa. C'è una tecnica molto semplice per capire esattamente come svn merge agisce.

The main source of confusion is the name of the command. The term “merge” somehow denotes that branches are combined together, or that there's some sort of mysterious blending of data going on. That's not the case. A better name for the command might have been svn diff-and-apply, because that's all that happens: two repository trees are compared, and the differences are applied to a working copy.

La fonte primaria della confusione è il nome del comando. Il termine «merge»(fondere) qualche volta denota che i rami sono combinati tra loro, oppure che ci sta qualche sorta di misterioso mescolamento dei dati. Non è il caso. Più appropriato nome per questo comando forse sarebbe svn diff-and-apply(trova-differenze-e-applicale), perché questo è tutto che accade: due strutture del deposito(repository) sono comparate e le differenze sono applicate alla copia di lavoro.

The command takes three arguments:

Il comando prende tre argomenti:

Once these three arguments are specified, the two trees are compared, and the resulting differences are applied to the target working copy as local modifications. When the command is done, the results are no different than if you had hand-edited the files, or run various svn add or svn delete commands yourself. If you like the results, you can commit them. If you don't like the results, you can simply svn revert all of the changes.

Una volta specificati questi tre argomenti, le due strutture sono comparate e le differenze risultanti sono applicate alla copia di lavoro destinataria come modifiche locali. Quando il comando finisce il suo lavoro, il risultato non è diverso da come aveste editato i file manualmente o aveste da soli avviato svariati comandi svn add o svn delete. Se il risultato vi piace, potete fare commit. Se non vi piace, con semplice comando svn revert scartate tutte le modifiche.

The syntax of svn merge allows you to specify the three necessary arguments rather flexibly. Here are some examples:

La sintassi di comando svn merge vi permete di specificare i tre argomenti necessari in modo molto flessibile Qui ci sono alcuni esempi:

$ svn merge http://svn.example.com/repos/branch1@150 \
            http://svn.example.com/repos/branch2@212 \
            my-working-copy

$ svn merge -r 100:200 http://svn.example.com/repos/trunk my-working-copy

$ svn merge -r 100:200 http://svn.example.com/repos/trunk

The first syntax lays out all three arguments explicitly, naming each tree in the form URL@REV and naming the working copy target. The second syntax can be used as a shorthand for situations when you're comparing two different revisions of the same URL. The last syntax shows how the working-copy argument is optional; if omitted, it defaults to the current directory.

La prima sintassi elenca tutti e tre argomenti esplicitamente, nominando ogni struttura in forma URL@REV e nominando la copia di lavoro ricevente. La seconda sintassi può essere usata, quando state comparando due versioni diverse dello stesso URL. L'ultima sintassi mostra che argomento 'copia di lavoro' è facoltativo; se omesso, il suo valore predefinito è la cartella attuale.

To complete our running example, we'll move forward in time. Suppose several days have passed, and many changes have happened on both the trunk and your private branch. Suppose that you've finished working on your private branch; the feature or bug fix is finally complete, and now you want to merge all of your branch changes back into the trunk for others to enjoy.

Per complettare nostro esempio in corso, ci moviamo avanti nel tempo. Supponiamo che sono passati diversi giorni, e sono accadute molte modifiche su tutte e due strutture, il tronco e vostro ramo privato. Supponiamo che avete finito il lavoro su vostro ramo privato; nuova caratteristica o riparazione del bug è finalmente completta e adesso volete fondere tutte le modifiche del vostro ramo dietro tronco, così che gl'altri possono assaporarle.

So how do we use svn merge in this scenario? Remember that this command compares two trees, and applies the differences to a working copy. So to receive the changes, you need to have a working copy of the trunk. We'll assume that either you still have your original one lying around (fully updated), or that you recently checked out a fresh working copy of /calc/trunk.

Allora, come usiamo svn merge in questo scenario? Ricordate che questo comando compara due strutture ed applica le differenze alla copia di lavoro. Perciò per scoprire le modifiche, avete bisogno della copia di lavoro del tronco. Assumiamo che o avete ancora quella originale da qualche parte (complettamente aggiornata) o che di recente avete tirato fuori (checkout) una fresca copia di /calc/trunk.

But which two trees should be compared? At first glance, the answer may seem obvious: just compare the latest trunk tree with your latest branch tree. But beware—this assumption is wrong, and has burned many a new user! Since svn merge operates like svn diff, comparing the latest trunk and branch trees will not merely describe the set of changes you made to your branch. Such a comparison shows too many changes: it would not only show the addition of your branch changes, but also the removal of trunk changes that never happened on your branch.

Ma quale due strutture devono essere comparate? A primo sguardo, la risposta sembra ovvia: comparare l'ultima struttura di tronco con l'ultima del ramo. Ferma!—questa ??assunzione? è sbagliata, e ha bruciato molti principianti! Perché svn merge opera come svn diff, comparare le ultime strutture di tronco e ramo non descriverà soltanto l'insieme delle modifiche fatte sul ramo. Comparazione come questa mostra trope modifiche: mostrerebbe non solo le agguinte delle vostre modifiche del ramo, ma anche le rimozioni delle modifiche del tronco che non sono mai accadute su vostro ramo.

To express only the changes that happened on your branch, you need to compare the initial state of your branch to its final state. Using svn log on your branch, you can see that your branch was created in revision 341. And the final state of your branch is simply a matter of using the HEAD revision. That means you want to compare revisions 341 and HEAD of your branch directory, and apply those differences to a working copy of the trunk.

Per scoprire solo le modifiche che son accadute nel vostro ramo, dovete comparare lo stato iniziale del ramo con il suo stato finale. Usando svn log sul vostro ramo, potete vedere che vostro ramo era stato creato nella versione 341. E lo stato finale è semplicemente questione di usare la versione HEAD. Questo significa che dovete comparare versione 341 e HEAD della cartella del vostro ramo e applicare quelle differenze all copia di lavoro del tronco.

Suggerimento

A nice way of finding the revision in which a branch was created (the “base” of the branch) is to use the --stop-on-copy option to svn log. The log subcommand will normally show every change ever made to the branch, including tracing back through the copy which created the branch. So normally, you'll see history from the trunk as well. The --stop-on-copy will halt log output as soon as svn log detects that its target was copied or renamed. Un bel modo per trovare la versione nella quale era stato creato un ramo (la «base» del ramo) è usare opzione --stop-on-copy nel svn log. Sottocomando log normalmente mostrerà ogni cambiamento fatto sul ramo, andando dietro anche prima della copiatura che ha creato il ramo. Così normalmente, vedremmo anche la parte della storia dal tronco. Lo --stop-on-copy fermerà output di log appena svn log scopre che il suo bersaglio era copiato o rinominato. So in our continuing example, Così nel nostro esempi continuo, $ svn log --verbose --stop-on-copy \ http://svn.example.com/repos/calc/branches/my-calc-branch … ------------------------------------------------------------------------ r341 | user | 2002-11-03 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines Changed paths: A /calc/branches/my-calc-branch (from /calc/trunk:340) $ As expected, the final revision printed by this command is the revision in which my-calc-branch was created by copying. Come aspettato, l'ultima versione stampata da questo comando è la versione in cui my-calc-branch era stato creato copiandolo.

Here's the final merging procedure, then:

Qui c'è la procedura di fusione finale, allora:

$ cd calc/trunk
$ svn update
At revision 405.

$ svn merge -r 341:405 http://svn.example.com/repos/calc/branches/my-calc-branch
U   integer.c
U   button.c
U   Makefile

$ svn status
M   integer.c
M   button.c
M   Makefile

# ...examine the diffs, compile, test, etc...

$ svn commit -m "Merged my-calc-branch changes r341:405 into the trunk."
Sending        integer.c
Sending        button.c
Sending        Makefile
Transmitting file data ...
Committed revision 406.

  $ cd calc/trunk
  $ svn update
  At revision 405.

  $ svn merge -r 341:405 http://svn.example.com/repos/calc/branches/my-calc-branch
  U   integer.c
  U   button.c
  U   Makefile

  $ svn status
  M   integer.c
  M   button.c
  M   Makefile

  # ...esaminare le diff, compilare, testare, ecc...

  $ svn commit -m "Fuso modifiche my-calc-branch r341:405 dentro tronco."
  Sending        integer.c
  Sending        button.c
  Sending        Makefile
  Transmitting file data ...
  Committed revision 406.

Again, notice that the commit log message very specifically mentions the range of changes that was merged into the trunk. Always remember to do this, because it's critical information you'll need later on.

Di nuovo, notare che messaggio di commit menziona molto specificamente intervallo delle modifiche che sono state fuse nel tronco. Ricordate sempre di farlo, perché più tardi avrete bisogno di questa critica informazione.

For example, suppose you decide to keep working on your branch for another week, in order to complete an enhancement to your original feature or bug fix. The repository's HEAD revision is now 480, and you're ready to do another merge from your private branch to the trunk. But as discussed in sezione chiamata «Regole d'arte per la fusione», you don't want to merge the changes you've already merged before; you only want to merge everything “new” on your branch since the last time you merged. The trick is to figure out what's new.

Per esempio, supponiamo che decidete di proseguire lavoro sul vostro ramo per altra settimana, onde complettare un miglioramento alla vostra caratteristica o bugfix. La versione HEAD del deposito(repository) è adesso 480, e voi siete pronti a fare altra fusione dal vostro ramo privato al tronco. Ma come era discusso nella sezione chiamata «Regole d'arte per la fusione», non volete fondere le modifiche che avevate già fuso prima; volete solo fondere tutto il «nuovo» dal vostro ramo a partire dalla ultima fusione. Il trucco sta nel scoprire che cosa è 'il nuovo'.

The first step is to run svn log on the trunk, and look for a log message about the last time you merged from the branch:

Il primo passo è avviare svn log su tronco e cercare messaggio riguardo l'ultima fusione dal ramo:

$ cd calc/trunk
$ svn log
…
------------------------------------------------------------------------
r406 | user | 2004-02-08 11:17:26 -0600 (Sun, 08 Feb 2004) | 1 line

Merged my-calc-branch changes r341:405 into the trunk.
------------------------------------------------------------------------
…

  $ cd calc/trunk
  $ svn log
  …
  ------------------------------------------------------------------------
  r406 | user | 2004-02-08 11:17:26 -0600 (Sun, 08 Feb 2004) | 1 line

  Fuso modifiche my-calc-branch r341:405 dentro tronco.
  ------------------------------------------------------------------------
  …

Aha! Since all branch-changes that happened between revisions 341 and 405 were previously merged to the trunk as revision 406, you now know that you want to merge only the branch changes after that—by comparing revisions 406 and HEAD.

Aha! Poiché tutte modifiche del ramo che sono state fatte tra le versioni 341 e 405 erano già precedentemente fuse nel tronco come versione 406, sapete adesso che volete fondere solo cambiamenti del ramo fatte dopo—comparando versioni 406 e HEAD.

$ cd calc/trunk
$ svn update
At revision 480.

# We notice that HEAD is currently 480, so we use it to do the merge:

$ svn merge -r 406:480 http://svn.example.com/repos/calc/branches/my-calc-branch
U   integer.c
U   button.c
U   Makefile

$ svn commit -m "Merged my-calc-branch changes r406:480 into the trunk."
Sending        integer.c
Sending        button.c
Sending        Makefile
Transmitting file data ...
Committed revision 481.

  $ cd calc/trunk
  $ svn update
  At revision 480.

  # Vediamo che HEAD è al momento 480, usiamo questa info per la fusione:

  $ svn merge -r 406:480 http://svn.example.com/repos/calc/branches/my-calc-branch
  U   integer.c
  U   button.c
  U   Makefile

  $ svn commit -m "Fuso modifiche my-calc-branch r406:480 dentro tronco."
  Sending        integer.c
  Sending        button.c
  Sending        Makefile
  Transmitting file data ...
  Committed revision 481.

Now the trunk contains the complete second wave of changes made to the branch. At this point, you can either delete your branch (we'll discuss this later on), or continue working on your branch and repeat this procedure for subsequent merges.

Adesso il tronco contiene la completta seconda ondata delle modifiche fatte sul ramo. A questo punto, potete o cancellare vostro ramo (discutteremmo questo più avanti), o continuare lavoro su vostro ramo e ripetere questa procedura con le fusioni venture.

Another common use for svn merge is to roll back a change that has already been committed. Suppose you're working away happily on a working copy of /calc/trunk, and you discover that the change made way back in revision 303, which changed integer.c, is completely wrong. It never should have been committed. You can use svn merge to “undo” the change in your working copy, and then commit the local modification to the repository. All you need to do is to specify a reverse difference:

Altro uso comune per svn merge è di riavvolgere dietro (disfare) le modifiche che sono state già depositate. Supponiamo che state proseguendo beatamente lavori sulla copia di lavoro del /calc/trunk, e avete scoperto che la modifica fatta nella versione 303, che ha cambiato integer.c, è complettamente sbagliata. Non doveva essere mai depositata. Potete usare svn merge per «disfare» la modifica nella vostra copia e dopo depositare la modifica locale. Tutto di cui avete bisogno è specificare la diffrenza rovesciata:

$ svn merge -r 303:302 http://svn.example.com/repos/calc/trunk
U  integer.c

$ svn status
M  integer.c

$ svn diff
…
# verify that the change is removed
…

$ svn commit -m "Undoing change committed in r303."
Sending        integer.c
Transmitting file data .
Committed revision 350.

  $ svn merge -r 303:302 http://svn.example.com/repos/calc/trunk
  U  integer.c

  $ svn status
  M  integer.c

  $ svn diff
  …
  # verificare che le modifiche sono state rimosse
  …

  $ svn commit -m "Disfatte le modifiche pubblicate nella r303."
  Sending        integer.c
  Transmitting file data .
  Committed revision 350.

One way to think about a repository revision is as a specific group of changes (some version control systems call these changesets). By using the -r switch, you can ask svn merge to apply a changeset, or whole range of changesets, to your working copy. In our case of undoing a change, we're asking svn merge to apply changeset #303 to our working copy backwards.

Un modo di pensare alle versioni del deposito(repository) è come allo specifico gruppo delle modifiche (alcuni sistemi di controllo delle versioni lo chiamano changeset). Usando opzione -r potete chiedere a svn merge di applicare un changeset, o tutto intervallo di changeset, alla vostra copia di lavoro. Nel nostro caso di disfare cambiamenti, stiamo chiedendo a svn merge di applicare changeset nr.303 sulla nostra copia di lavoro al rovescio.

Keep in mind that rolling back a change like this is just like any other svn merge operation, so you should use svn status and svn diff to confirm that your work is in the state you want it to be in, and then use svn commit to send the final version to the repository. After committing, this particular changeset is no longer reflected in the HEAD revision.

Tenete in mente che disfare (riavvolgere dietro) una modifica è come ogni altra operazione svn merge, così dovete usare svn status e svn diff per confermare che vostro lavoro è nello stato voluto, e poi usare svn commit per spedire la versione finale al deposito(repository). Dopo deposizione quello particolare changeset non è più presente nella versione HEAD.

Again, you may be thinking: well, that really didn't undo the commit, did it? The change still exists in revision 303. If somebody checks out a version of the calc project between revisions 303 and 349, they'll still see the bad change, right?

Di nuovo, potete pensare: Insomma, questo in verità non disfa una deposizione, dico bene? La modifica ancora esiste nella versione 303. Se qualcuno tira fuori una versione di progetto calc tra versioni 303 e 349, può ancora vedere la modifica errata, vero?

Yes, that's true. When we talk about “removing” a change, we're really talking about removing it from HEAD. The original change still exists in the repository's history. For most situations, this is good enough. Most people are only interested in tracking the HEAD of a project anyway. There are special cases, however, where you really might want to destroy all evidence of the commit. (Perhaps somebody accidentally committed a confidential document.) This isn't so easy, it turns out, because Subversion was deliberately designed to never lose information. Revisions are immutable trees which build upon one another. Removing a revision from history would cause a domino effect, creating chaos in all subsequent revisions and possibly invalidating all working copies. ^[19]

Sì, questo è vero. Quando abbiamo parlato di «rimuovere» una modifica, in verità abbiamo parlato di rimuoverla dalla versione HEAD. Il cambiamento originale ancora esiste nella storia del deposito(repository). Per la maggioranza delle situazioni questo basta. Tanto, molte persone sono interessate solo di usare HEAD del progetto. Ci sono, comunque, casi speciali, in cui veramente volete distruggere ogni traccia della deposizione avvenuta. (Magari qualcuno ha accidentalmente pubblicato un documento riservato.) Si scopre che non è così facile, perché Subversion era stato volutamente disegnato per non perdere mai le informazioni. Versioni sono strutture ad albero immutabili basati una sull'altra. Togliendo una revisione dalla storia può causare un effetto domino, creando chaos in tutte le subsequenti versioni e possibilmente invalidare tutte le copie di lavoro. ^[20]

The great thing about version control systems is that information is never lost. Even when you delete a file or directory, it may be gone from the HEAD revision, but the object still exists in earlier revisions. One of the most common questions new users ask is, “How do I get my old file or directory back?”.

La cosa grande nei sistemi di controllo delle versioni è che la informazione non si perde mai. Addirittura quando cancellate un file o cartella, può sparire dalla versione HEAD, ma l'elemento sempre esiste nelle versioni precedenti. Una delle più comuni domande degli nuovi utenti è «Come posso riavere mio vecchio file o cartella?».

The first step is to define exactly which item you're trying to resurrect. Here's a useful metaphor: you can think of every object in the repository as existing in a sort of two-dimensional coordinate system. The first coordinate is a particular revision tree, and the second coordinate is a path within that tree. So every version of your file or directory can be defined by a specific coordinate pair.

Il primo passo è di definire precisamente quale elemento state provando di risuscitare. Qui c'è una utile metafora: potete pensare ad ogni oggetto del deposito(repository) come essistesse in una sorta di spazio bidimensionale. La prima coordinata è la particolare versione e la seconda è il percorso e nome dentro questa versione. Così ogni versione del vostro file o cartella può essere definita da una copia di coordinate specifica.

Subversion has no Attic directory like CVS does, ^[21] so you need to use svn log to discover the exact coordinate pair you wish to resurrect. A good strategy is to run svn log --verbose in a directory which used to contain your deleted item. The --verbose option shows a list of all changed items in each revision; all you need to do is find the revision in which you deleted the file or directory. You can do this visually, or by using another tool to examine the log output (via grep, or perhaps via an incremental search in an editor).

Subversion no ha cartella Attic come la tiene CVS, ^[22] e perciò dovete usare svn log per scoprire la copia esatta di coordinate del elemento da risuscitare. Una strategia buona è di avviare svn log --verbose nella cartella che abitulamente conteneva vostro elemento cancellato. La opzione --verbose mostra la lista di tutte le modifiche in ogni versione; tutto di cui avete bisogno è trovare versione in cui l'elemento era stato cancellato. Potete farlo a vista o usando qualche strumento per essaminare output di log (tramite grep, o forse con una ricerca incrementale in un editore).

$ cd parent-dir
$ svn log --verbose
…
------------------------------------------------------------------------
r808 | joe | 2003-12-26 14:29:40 -0600 (Fri, 26 Dec 2003) | 3 lines
Changed paths:
   D /calc/trunk/real.c
   M /calc/trunk/integer.c

Added fast fourier transform functions to integer.c.
Removed real.c because code now in double.c.
…

  $ cd parent-dir
  $ svn log --verbose
  …
  ------------------------------------------------------------------------
  r808 | joe | 2003-12-26 14:29:40 -0600 (Fri, 26 Dec 2003) | 3 lines
  Changed paths:
  D /calc/trunk/real.c
  M /calc/trunk/integer.c

  Aggiunta la funzione di trasformazione Fourier veloce a integer.c.
  Rimosso real.c perché il codice è adesso in double.c.
  …

In the example, we're assuming that you're looking for a deleted file real.c. By looking through the logs of a parent directory, you've spotted that this file was deleted in revision 808. Therefore, the last version of the file to exist was in the revision right before that. Conclusion: you want to resurrect the path /calc/trunk/real.c from revision 807.

Nel esempio abbiamo assunto che state cercando file cancellato real.c. Scorrendo tra log della sua cartella parente, avete scoperto che questo file era stato cancellato nella versione 808. In consequenza, l'ultima versione che lo contiene è quella subito prima. Conclusione: dovete risuscitare /calc/trunk/real.c della versione 807.

That was the hard part—the research. Now that you know what you want to restore, you have two different choices.

Quella era la parte dura—la ricerca. Adesso che sappiamo che cosa riprendere, abbiamo due diverse scelte.

One option is to use svn merge to apply revision 808 “in reverse”. (We've already discussed how to undo changes, see sezione chiamata «Disfare i cambiamenti».) This would have the effect of re-adding real.c as a local modification. The file would be scheduled for addition, and after a commit, the file would again exist in HEAD.

Una opzione è usare svn merge per applicare versione 808 «al rovescio». (Abbiamo già discusso come disfare le modifiche, vedi sezione chiamata «Disfare i cambiamenti».) Questo potrebbe avere effetto di ri-aggiungere real.c come una modifica locale. Il file sarà pianificato per aggiunta e dopo deposizione essisterà di nuovo nel HEAD.

In this particular example, however, this is probably not the best strategy. Reverse-applying revision 808 would not only schedule real.c for addition, but the log message indicates that it would also undo certain changes to integer.c, which you don't want. Certainly, you could reverse-merge revision 808 and then svn revert the local modifications to integer.c, but this technique doesn't scale well. What if there were 90 files changed in revision 808?

In questo esempio particolare, ??however?, questa probabilmente non è la strategia migliore. Applicazione al rovescio della versione 808 non solo pianificherà real.c per aggiunta, ma il messagio di log indica che disfarà anche certe modifiche del file integer.c, ciò che non vogliamo. Naturalmente, potete fare fusione al rovescio di versione 808 e dopo disfare modifiche locali del file integer.c con svn revert, ma questa tecnica non si adatta bene al aumento del lavoro. Cosa fare se ci fossero 90 file modificati nella versione 808?

A second, more targeted strategy is not to use svn merge at all, but rather the svn copy command. Simply copy the exact revision and path “coordinate pair” from the repository to your working copy:

Una seconda strategia, più mirata, è di non usare del tutto svn merge, ma invece il comando svn copy. Semplicemete copiate esatte «coordinate» (revisone e percorso-nome) dal deposito(repository) alla vostra copia di lavoro:

$ svn copy --revision 807 \
           http://svn.example.com/repos/calc/trunk/real.c ./real.c

$ svn status
A  +   real.c

$ svn commit -m "Resurrected real.c from revision 807, /calc/trunk/real.c."
Adding         real.c
Transmitting file data .
Committed revision 1390.

$ svn copy --revision 807 \
           http://svn.example.com/repos/calc/trunk/real.c ./real.c

$ svn status
A  +   real.c

$ svn commit -m "Risuscitato real.c dalla versione 807, /calc/trunk/real.c."
Adding         real.c
Transmitting file data .
Committed revision 1390.

The plus sign in the status output indicates that the item isn't merely scheduled for addition, but scheduled for addition “with history”. Subversion remembers where it was copied from. In the future, running svn log on this file will traverse back through the file's resurrection and through all the history it had prior to revision 807. In other words, this new real.c isn't really new; it's a direct descendant of the original, deleted file.

Il segno più nel output di status indica che l'elemento non è solo pianificato per aggiunta, ma per aggiunta «con storico». Subversion si ricorda da dove era stato copiato. In futuro, usando svn log su di questo file attraversiammo dietro la sua resurrezione e vedremmo tutta la sua storia che aveva prima della versione 807. In altre parole, questo nuovo real.c non è veramente nuovo; è un discendente diretto del file originale cancellato.

Although our example shows us resurrecting a file, note that these same techniques work just as well for resurrecting deleted directories.

Nonostante nostro esempio ci mostra resurrezione di un file, notare che la stessa tecnica serve anche per resurrezione delle cartelle cancellate.

Version control is most often used for software development, so here's a quick peek at two of the most common branching/merging patterns used by teams of programmers. If you're not using Subversion for software development, feel free to skip this section. If you're a software developer using version control for the first time, pay close attention, as these patterns are often considered best practices by experienced folk. These processes aren't specific to Subversion; they're applicable to any version control system. Still, it may help to see them described in Subversion terms.

Controllo delle versioni è molto spesso usato per sviluppo del software, così abbiamo qui una veloce sbirciatina di due più comuni archetipi di ramificazione usati dai team di programmatori. Se non usate Subversion per sviluppo di software, sentitevi liberi di saltare questa sezione.[alternativa: Se non è il vostro caso, potete tranquilmente saltare questa sezione.] Se siete sviluppatore di software alle prime armi con l'uso di controllo delle versioni, prestate molta attenzione, perché questi archetipi sono spesso considerati regola d'arte dalla gente esperta. Queste procedure non sono specifiche di Subversion; sono applicabili a qualsiasi sistema di controllo delle versioni. Tuttavia, può essere d'aiuto vederle descritte in termini di Subversion.

$ cd trunk-working-copy

$ svn update
At revision 1910.

$ svn merge http://svn.example.com/repos/calc/trunk@1910 \
            http://svn.example.com/repos/calc/branches/mybranch@1910
U  real.c
U  integer.c
A  newdirectory
A  newdirectory/newfile
…

Once again, svn copy comes to the rescue. If you want to create a snapshot of /calc/trunk exactly as it looks in the HEAD revision, then make a copy of it:

Ancora una volta, svn copy vi dà una mano. Se volete creare un'instantanea di /calc/trunk esattamente come compare nella versione HEAD, fate una copia di esso:

$ svn copy http://svn.example.com/repos/calc/trunk \
           http://svn.example.com/repos/calc/tags/release-1.0 \
      -m "Tagging the 1.0 release of the 'calc' project."

Committed revision 351.

  $ svn copy http://svn.example.com/repos/calc/trunk \
  http://svn.example.com/repos/calc/tags/release-1.0 \
  -m "Targato il rilascio 1.0 del progetto 'calc'."

  Committed revision 351.

This example assumes that a /calc/tags directory already exists. (If it doesn't, vedi svn mkdir). After the copy completes, the new release-1.0 directory is forever a snapshot of how the project looked in the HEAD revision at the time you made the copy. Of course you might want to be more precise about exactly which revision you copy, in case somebody else may have committed changes to the project when you weren't looking. So if you know that revision 350 of /calc/trunk is exactly the snapshot you want, you can specify it by passing -r 350 to the svn copy command.

Questo esempio presume che cartella /calc/tags già esiste. (Se no, vedi svn mkdir). Dopo che la copia è completata, la nuova cartella release-1.0 è per sempre un'instantanea come il progetto appariva nella versione HEAD in momento della copiatura. Certo, potete forse volere di essere più precisi nello stabilire quale versione copiare, in caso che qualcun altro aveva depositato cambiamenti quando non avete guardato. Sapendo che la versione 350 di /calc/trunk è proprio quella voluta, potete specificarlo passando opzione -r 350 al comando svn copy.

But wait a moment: isn't this tag-creation procedure the same procedure we used to create a branch? Yes, in fact, it is. In Subversion, there's no difference between a tag and a branch. Both are just ordinary directories that are created by copying. Just as with branches, the only reason a copied directory is a “tag” is because humans have decided to treat it that way: as long as nobody ever commits to the directory, it forever remains a snapshot. If people start committing to it, it becomes a branch.

Ma aspettate un po': la procedura di creare una targa non è la stessa come creare un ramo? Sì, infatti, lo è. In Subversion non c'è differenza tra targa e ramo. Entrambi sono ordinarie cartelle e sono creati tramite copiatura. Uguale come per i rami, l'unica ragione che una cartella copiata è una «targa» è perché esseri umani hanno deciso di trattarla in quel modo: finché nessuno fa commit su questa cartella, rimane per sempre un'instantanea. Se la gente comincia a depositare dentro (commit), diventa un ramo.

If you are administering a repository, there are two approaches you can take to managing tags. The first approach is “hands off”: as a matter of project policy, decide where your tags will live, and make sure all users know how to treat the directories they copy in there. (That is, make sure they know not to commit to them.) The second approach is more paranoid: you can use one of the access-control scripts provided with Subversion to prevent anyone from doing anything but creating new copies in the tags-area (See Capitolo 6, Configurazione del server.) The paranoid approach, however, isn't usually necessary. If a user accidentally commits a change to a tag-directory, you can simply undo the change as discussed in the previous section. This is version control, after all.

Se state amministrando un deposito(repository), ci sono due approci da prendere per maneggiare targhe. Il primo approcio è «alzare le mani»: nelle regole del progetto decidete dove vivranno le targhe e assicurate che tutti utenti capiscono come trattare le cartelle che copiano lì. (Proprio così, assicuratevi che sanno di non fare commit su di essi.^[26]) Il secondo approcio è più paranoico. Potete usare uno dei script di controllo d'accesso forniti con Subversion per prevenire che nell'area delle targhe nessuno può fare altro che creare nuove copie. (Vedi Capitolo 6, Configurazione del server.) L'approcio paranoico, comunque, non è tanto necessario. Se un utente accidentalmente fa un commit nella cartella delle targhe, potete semplicemente disfare la modifica come abbiamo discuso nella sezione precedente. Oltrettuto, stiamo usando controllo delle versioni, no?

Sometimes you may want your “snapshot” to be more complicated than a single directory at a single revision.

Qualche volta potete desiderare che vostra «instantanea» sarà più complicata di una singola cartella della singola revisione.

For example, pretend your project is much larger than our calc example: suppose it contains a number of subdirectories and many more files. In the course of your work, you may decide that you need to create a working copy that is designed to have specific features and bug fixes. You can accomplish this by selectively backdating files or directories to particular revisions (using svn update -r liberally), or by switching files and directories to particular branches (making use of svn switch). When you're done, your working copy is a hodgepodge of repository locations from different revisions. But after testing, you know it's the precise combination of data you need.

For example, pretend your project is much larger than our calc example: supponiamo che contiene gran numero di sottocartelle e molto di più file. Nel corso del vostro lavoro potete decidere che avete bisogno di creare una copia di lavoro progettata per avere specifiche caratteristiche e bug fix. You can accomplish this by selectively backdating files or directories to particular revisions (using svn update -r liberally), or by switching files and directories to particular branches (making use of svn switch). Dopo aver finito, vostra copia di lavoro è un groviglio delle locazioni del deposito(repository) dalle diverse versioni. Ma dopo i test, sapete che questa è la precisa combinazione dei dati che vi serve.

Time to make a snapshot. Copying one URL to another won't work here. In this case, you want to make a snapshot of your exact working copy arrangement and store it in the repository. Luckily, svn copy actually has four different uses (which you can read about in Chapter 9), including the ability to copy a working-copy tree to the repository:

Ora di scattare un'instantanea. Copying one URL to another won't work here. In this case, you want to make a snapshot of your exact working copy arrangement and store it in the repository. Luckily, svn copy actually has four different uses (which you can read about in Capitolo 9, Riferimento completo di Subversion), incluso la capacità di copiare una copia di lavoro nel deposito(repository):

$ ls
my-working-copy/

$ svn copy my-working-copy http://svn.example.com/repos/calc/tags/mytag

Committed revision 352.

Now there is a new directory in the repository, /calc/tags/mytag, which is an exact snapshot of your working copy—mixed revisions, URLs, and all.

Adesso nel deposito(repository) c'è una nuova cartella, /calc/tags/mytag, che è un'instantanea esatta della vostra copia di lavoro—revisioni miste, URL, e tutto il resto.

Other users have found interesting uses for this feature. Sometimes there are situations where you have a bunch of local changes made to your working copy, and you'd like a collaborator to see them. Instead of running svn diff and sending a patch file (which won't capture tree changes, symlink changes or changes in properties), you can instead use svn copy to “upload” your working copy to a private area of the repository. Your collaborator can then either checkout a verbatim copy of your working copy, or use svn merge to receive your exact changes.

Altri utenti hanno trovato usi interessanti per questa caratteristica. Di tanto in tanto sono le situazioni avete una manciata delle modifiche locali fatte sulla vostra copia di lavoro e volete farle vedere ai vostri collaboratori. Invece di usare svn diff e mandarli file patch (che non può catturare cambiamenti di cartelle, link simbolici oppure cambiamenti delle proprietà) potete usare svn copy per «caricare» la vostra copia di lavoro nella area privata del deposito(repository). Vostro collaboratore può poi o tirarsi fuori una copia identica (checkout) o usare svn merge per ricevere le vostre modifiche.

There are some standard, recommended ways to organize a repository. Most people create a trunk directory to hold the “main line” of development, a branches directory to contain branch copies, and a tags directory to contain tag copies. If a repository holds only one project, then often people create these top-level directories:

Ci sono alcuni standard, modi raccommandati per organizzare un deposito(repository). Molti creano una cartella trunk per contenere «linea principale» dello sviluppo, una cartella branches per contenere i rami e una cartella tags per contenere le targhe. Quando il deposito(repository) contiene solo un progetto, allora si creano queste cartelle di alto livello:

/trunk
/branches
/tags

If a repository contains multiple projects, admins typically index their layout by project (see sezione chiamata «Choosing a Repository Layout» to read more about “project roots”):

Quando il deposito(repository) contiene più progetti, amministratori tipicamente dividono la disposizione secondo i progetti (vedi sezione chiamata «Choosing a Repository Layout» per leggere di più riguardo «radici dei progetti»):

/paint/trunk
/paint/branches
/paint/tags
/calc/trunk
/calc/branches
/calc/tags

Of course, you're free to ignore these common layouts. You can create any sort of variation, whatever works best for you or your team. Remember that whatever you choose, it's not a permanent commitment. You can reorganize your repository at any time. Because branches and tags are ordinary directories, the svn move command can move or rename them however you wish. Switching from one layout to another is just a matter of issuing a series of server-side moves; if you don't like the way things are organized in the repository, just juggle the directories around.

Of course, you're free to ignore these common layouts. You can create any sort of variation, whatever works best for you or your team. Remember that whatever you choose, it's not a permanent commitment. You can reorganize your repository at any time. Because branches and tags are ordinary directories, the svn move command can move or rename them however you wish. Switching from one layout to another is just a matter of issuing a series of server-side moves; if you don't like the way things are organized in the repository, just juggle the directories around.

Remember, though, that while moving directories may be easy to do, you need to be considerate of your users as well. Your juggling can be disorienting to users with existing working copies. If a user has a working copy of a particular repository directory, your svn move operation might remove the path from the latest revision. When the user next runs svn update, she will be told that her working copy represents a path that no longer exists, and the user will be forced to svn switch to the new location.

Ricordatevi, though, that while moving directories may be easy to do, you need to be considerate of your users as well. Your juggling can be disorienting to users with existing working copies. If a user has a working copy of a particular repository directory, your svn move operation might remove the path from the latest revision. When the user next runs svn update, she will be told that her working copy represents a path that no longer exists, and the user will be forced to svn switch to the new location.

Another nice feature of Subversion's model is that branches and tags can have finite lifetimes, just like any other versioned item. For example, suppose you eventually finish all your work on your personal branch of the calc project. After merging all of your changes back into /calc/trunk, there's no need for your private branch directory to stick around anymore:

Altra bella caratteristica del modello Subversionè che i rami e targhe hanno la vita limitata, come qualsiasi altro articolo[pezzo] versionato. Per esempio, supponiamo che avete finito lavoro su vostro ramo personale di progetto calc. Dopo fusione delle tutte vostre modifiche indietro nel /calc/trunk, non c'è più ragione per la essistenza del ramo privato:

$ svn delete http://svn.example.com/repos/calc/branches/my-calc-branch \
             -m "Removing obsolete branch of calc project."

Committed revision 375.

  $ svn delete http://svn.example.com/repos/calc/branches/my-calc-branch \
             -m "Rimosso ramo obsoletto del progetto calc."

  Committed revision 375.

And now your branch is gone. Of course it's not really gone: the directory is simply missing from the HEAD revision, no longer distracting anyone. If you use svn checkout, svn switch, or svn list to examine an earlier revision, you'll still be able to see your old branch.

E adesso vostro ramo è andato. Certo, in verità non è sparito: la cartella semplicemente manca nella versione HEAD, non distraendo più nessuno. Usando svn checkout, svn switch, o svn list per essaminare le versioni precedenti, potete ancora vedere vostro vecchio ramo.

If browsing your deleted directory isn't enough, you can always bring it back. Resurrecting data is very easy in Subversion. If there's a deleted directory (or file) that you'd like to bring back into HEAD, simply use svn copy -r to copy it from the old revision:

Se non vi basta navigare nella cartella cancellata, potete sempre richiamarla dietro. Risurrezione dei dati è in Subversion molto semplice. If there's a deleted directory (or file) that you'd like to bring back into HEAD, simply use svn copy -r to copy it from the old revision:

$ svn copy -r 374 http://svn.example.com/repos/calc/branches/my-calc-branch \
                  http://svn.example.com/repos/calc/branches/my-calc-branch

Committed revision 376.

In our example, your personal branch had a relatively short lifetime: you may have created it to fix a bug or implement a new feature. When your task is done, so is the branch. In software development, though, it's also common to have two “main” branches running side-by-side for very long periods. For example, suppose it's time to release a stable version of the calc project to the public, and you know it's going to take a couple of months to shake bugs out of the software. You don't want people to add new features to the project, but you don't want to tell all developers to stop programming either. So instead, you create a “stable” branch of the software that won't change much:

Nel nostro esempio, vostro ramo personale aveva la vita relativamente breve: lo avete creato per bug fix o sviluppo d'una nuova caratteristica. Quando vostro lavoro era fatto, era finito anche il ramo. Nello sviluppo di software, invece, è comune di avere due «principali» rami affiancati per lungo periodo di tempo. Per esempio, supponiamo che è giunta ora di rilasciare la versione stabile di progetto calc al pubblico, e voi sapete che ci vorrà qualche mese per cacciare via dal software gli errori. Non volete che la gente aggiunga nuove caratteristiche al progetto, ma non volete neanche fermare gli sviluppatori. Allora, create un ramo«stable» del software che non cambierà molto:

$ svn copy http://svn.example.com/repos/calc/trunk \
         http://svn.example.com/repos/calc/branches/stable-1.0 \
         -m "Creating stable branch of calc project."

Committed revision 377.

  $ svn copy http://svn.example.com/repos/calc/trunk \
  http://svn.example.com/repos/calc/branches/stable-1.0 \
  -m "Creato ramo stabile del progetto calc."

  Committed revision 377.

And now developers are free to continue adding cutting-edge (or experimental) features to /calc/trunk, and you can declare a project policy that only bug fixes are to be committed to /calc/branches/stable-1.0. That is, as people continue to work on the trunk, a human selectively ports bug fixes over to the stable branch. Even after the stable branch has shipped, you'll probably continue to maintain the branch for a long time—that is, as long as you continue to support that release for customers.

Adesso gli sviluppatori sono liberi di continuare ad aggiungere caratteristiche all'avanguardia (o sperimentali) al /calc/trunk, e voi potete stabilire la regola del progetto che solo i bug fix possono essere pubblicati nel /calc/branches/stable-1.0. Proprio così, mentre continua il lavoro sul tronco, qualcuno a mano porta selettivamente i bug fix sul ramo stabile. Anche dopo la uscita del ramo stabile al pubblico, probabilmente continuerete mantenere il ramo per lungo tempo—finché continuerà il supporto di questa versione per i clienti.

Conceptually speaking, a Subversion repository is a sequence of directory trees. Each tree is a snapshot of how the files and directories versioned in your repository looked at some point in time. These snapshots are created as a result of client operations, and are called revisions.

Parlando concettualmente, un repository Subversion è una sequenza di alberi di directory. Ogni albero è un'instantanea di come i file e le directory, sotto controllo di versione, appaiono in un particolare momento. Queste instantanee sono create in seguito ad un operazione effettuata su un client Subversion e vengono chiamate revisioni.

Every revision begins life as a transaction tree. When doing a commit, a client builds a Subversion transaction that mirrors their local changes (plus any additional changes that might have been made to the repository since the beginning of the client's commit process), and then instructs the repository to store that tree as the next snapshot in the sequence. If the commit succeeds, the transaction is effectively promoted into a new revision tree, and is assigned a new revision number. If the commit fails for some reason, the transaction is destroyed and the client is informed of the failure.

Ogni revisione inizia la sua vita come un albero di transazione. Quando si effettua un commit, il client crea una transazione Subversion che rispecchia i cambiamenti locali (più ogni altro cambiamento nel repository che magari è avvenuto dall'inizio del processo di commit del client) e successivamente da le istruzione al repository di salvare questo albero come la istantanea successiva nella sequenza. Se il commit ha successo, la transazione è promossa in un nuovo albero di revisione e viene assegnato un nuovo numero di revisione. Se il commit fallisce per qualche ragione, la transazione viene distrutta e il client viene informato della non andata a buon fine.

Updates work in a similar way. The client builds a temporary transaction tree that mirrors the state of the working copy. The repository then compares that transaction tree with the revision tree at the requested revision (usually the most recent, or “youngest” tree), and sends back information that informs the client about what changes are needed to transform their working copy into a replica of that revision tree. After the update completes, the temporary transaction is deleted.

Gli update funzionano quasi nello stesso modo. Il client crea un albero di transazione temporanea che rispecchia lo stato della copia di lavoro. Successivamente, il Repository confronta questo albero di transazione con l'albero di revisione della revisione richiesta (normalmente il più recente o «il più giovane » albero) e spedisce indietro le informazione che informano il client di quali cambiamenti sono necessari per trasformare la copia di lavoro in una replica di quel particolare albero di revisione. Dopo la fine dellàupdate la transazione temporanea viene cancellata.

The use of transaction trees is the only way to make permanent changes to a repository's versioned filesystem. However, it's important to understand that the lifetime of a transaction is completely flexible. In the case of updates, transactions are temporary trees that are immediately destroyed. In the case of commits, transactions are transformed into permanent revisions (or removed if the commit fails). In the case of an error or bug, it's possible that a transaction can be accidentally left lying around in the repository (not really affecting anything, but still taking up space).

L'uso degli alberi di transazione è l'unico modo di rendere permanenti i cambiamenti ad il filesystem di un repository sotto controllo di versione. Comunque, è importante capire che la durata della vita di una transazione è completamente flessibile. Nel caso degli update, le transazioni sono alberi temporanei che vengono immediatamante distrutti. Nel caso dei commit, le transazioni sono trasformate in revisioni permanenti ( o rimosse se il commit fallisce). Nel caso di un errore o di un bug, è possibile che una transazione, accidentalmente, venga lasciata nel repository (questo non crea nessun problema ma occupa solo spazio)

In theory, someday whole workflow applications might revolve around more fine-grained control of transaction lifetime. It is feasible to imagine a system whereby each transaction slated to become a revision is left in stasis well after the client finishes describing its changes to repository. This would enable each new commit to be reviewed by someone else, perhaps a manager or engineering QA team, who can choose to promote the transaction into a revision, or abort it.

In teoria, un giorno, tutte le applicazioni per gestire i workflow potrebbero girare attorno ad un sistema più raffinato per il controllo della vita delle transazioni. E' plausibile immaginare un sistema in cui ogni transazione candidata a diventare una revisione sia lasciata in stasi anche dopo che il client ha finito di descrivere i suoi cambiamenti al repository. Questo permetterebbe che ogni nuovo commit possa essere revisionato da qualcuno, tipicamente un manager oppure da un team QA di ingegneri, i quali possono decidete se promuovere la transazione in una revisione o annullarla.

Transactions and revisions in the Subversion repository can have properties attached to them. These properties are generic key-to-value mappings, and are generally used to store information about the tree to which they are attached. The names and values of these properties are stored in the repository's filesystem, along with the rest of your tree data.

Revision and transaction properties are useful for associating information with a tree that is not strictly related to the files and directories in that tree—the kind of information that isn't managed by client working copies. For example, when a new commit transaction is created in the repository, Subversion adds a property to that transaction named svn:date—a datestamp representing the time that the transaction was created. By the time the commit process is finished, and the transaction is promoted to a permanent revision, the tree has also been given a property to store the username of the revision's author (svn:author) and a property to store the log message attached to that revision (svn:log).

Revision and transaction properties are unversioned properties—as they are modified, their previous values are permanently discarded. Also, while revision trees themselves are immutable, the properties attached to those trees are not. You can add, remove, and modify revision properties at any time in the future. If you commit a new revision and later realize that you had some misinformation or spelling error in your log message, you can simply replace the value of the svn:log property with a new, corrected log message.

As of Subversion 1.1, there are two options for storing data in a Subversion repository. One type of repository stores everything in a Berkeley DB database; the other kind stores data in ordinary flat files, using a custom format. Because Subversion developers often refer to a repository as «the (versioned) filesystem», they have adopted the habit of referring to the latter type of repository as FSFS ^[29] —a versioned filesystem implementation that uses the native OS filesystem to store data.

When a repository is created, an administrator must decide whether it will use Berkeley DB or FSFS. There are advantages and disadvantages to each, which we'll describe in a bit. Neither back-end is more «official» than another, and programs which access the repository are insulated from this implementation detail. Programs have no idea how a repository is storing data; they only see revision and transaction trees through the repository API.

Tabella 5.1, «Repository Data Store Comparison» gives a comparative overview of Berkeley DB and FSFS repositories. The next sections go into detail.

A hook is a program triggered by some repository event, such as the creation of a new revision or the modification of an unversioned property. Each hook is handed enough information to tell what that event is, what target(s) it's operating on, and the username of the person who triggered the event. Depending on the hook's output or return status, the hook program may continue the action, stop it, or suspend it in some way.

The hooks subdirectory is, by default, filled with templates for various repository hooks.

$ ls repos/hooks/
post-commit.tmpl          post-unlock.tmpl          pre-revprop-change.tmpl
post-lock.tmpl            pre-commit.tmpl           pre-unlock.tmpl
post-revprop-change.tmpl  pre-lock.tmpl             start-commit.tmpl

There is one template for each hook that the Subversion repository implements, and by examining the contents of those template scripts, you can see what triggers each such script to run and what data is passed to that script. Also present in many of these templates are examples of how one might use that script, in conjunction with other Subversion-supplied programs, to perform common useful tasks. To actually install a working hook, you need only place some executable program or script into the repos/hooks directory which can be executed as the name (like start-commit or post-commit) of the hook.

On Unix platforms, this means supplying a script or program (which could be a shell script, a Python program, a compiled C binary, or any number of other things) named exactly like the name of the hook. Of course, the template files are present for more than just informational purposes—the easiest way to install a hook on Unix platforms is to simply copy the appropriate template file to a new file that lacks the .tmpl extension, customize the hook's contents, and ensure that the script is executable. Windows, however, uses file extensions to determine whether or not a program is executable, so you would need to supply a program whose basename is the name of the hook, and whose extension is one of the special extensions recognized by Windows for executable programs, such as .exe or .com for programs, and .bat for batch files.

Suggerimento

For security reasons, the Subversion repository executes hook scripts with an empty environment—that is, no environment variables are set at all, not even $PATH or %PATH%. Because of this, a lot of administrators are baffled when their hook script runs fine by hand, but doesn't work when run by Subversion. Be sure to explicitly set environment variables in your hook and/or use absolute paths to programs.

There are nine hooks implemented by the Subversion repository:

Avvertimento

Do not attempt to modify the transaction using hook scripts. A common example of this would be to automatically set properties such as svn:eol-style or svn:mime-type during the commit. While this might seem like a good idea, it causes problems. The main problem is that the client does not know about the change made by the hook script, and there is no way to inform the client that it is out-of-date. This inconsistency can lead to surprising and unexpected behavior. Instead of attempting to modify the transaction, it is much better to check the transaction in the pre-commit hook and reject the commit if it does not meet the desired requirements.

Subversion will attempt to execute hooks as the same user who owns the process which is accessing the Subversion repository. In most cases, the repository is being accessed via Apache HTTP server and mod_dav_svn, so this user is the same user that Apache runs as. The hooks themselves will need to be configured with OS-level permissions that allow that user to execute them. Also, this means that any file or programs (including the Subversion repository itself) accessed directly or indirectly by the hook will be accessed as the same user. In other words, be alert to potential permission-related problems that could prevent the hook from performing the tasks you've written it to perform.

A Berkeley DB environment is an encapsulation of one or more databases, log files, region files and configuration files. The Berkeley DB environment has its own set of default configuration values for things like the number of database locks allowed to be taken out at any given time, or the maximum size of the journaling log files, etc. Subversion's filesystem code additionally chooses default values for some of the Berkeley DB configuration options. However, sometimes your particular repository, with its unique collection of data and access patterns, might require a different set of configuration option values.

The folks at Sleepycat (the producers of Berkeley DB) understand that different databases have different requirements, and so they have provided a mechanism for overriding at runtime many of the configuration values for the Berkeley DB environment. Berkeley checks for the presence of a file named DB_CONFIG in each environment directory, and parses the options found in that file for use with that particular Berkeley environment.

The Berkeley configuration file for your repository is located in the db environment directory, at repos/db/DB_CONFIG. Subversion itself creates this file when it creates the rest of the repository. The file initially contains some default options, as well as pointers to the Berkeley DB online documentation so you can read about what those options do. Of course, you are free to add any of the supported Berkeley DB options to your DB_CONFIG file. Just be aware that while Subversion never attempts to read or interpret the contents of the file, and makes no use of the option settings in it, you'll want to avoid any configuration changes that may cause Berkeley DB to behave in a fashion that is unexpected by the rest of the Subversion code. Also, changes made to DB_CONFIG won't take effect until you recover the database environment (using svnadmin recover).

Subversion provides a handful of utilities useful for creating, inspecting, modifying and repairing your repository. Let's look more closely at each of those tools. Afterward, we'll briefly examine some of the utilities included in the Berkeley DB distribution that provide functionality specific to your repository's database backend not otherwise provided by Subversion's own tools.

$ svnlook help
general usage: svnlook SUBCOMMAND REPOS_PATH [ARGS & OPTIONS ...]
Note: any subcommand which takes the '--revision' and '--transaction'
      options will, if invoked without one of those options, act on
      the repository's youngest revision.
Type "svnlook help <subcommand>" for help on a specific subcommand.
…

$ svnlook info /path/to/repos
$ svnlook info /path/to/repos --revision 19

$ svnlook youngest /path/to/repos
19

$ svnlook info /path/to/repos
sally
2002-11-04 09:29:13 -0600 (Mon, 04 Nov 2002)
27
Added the usual
Greek tree.