The svn:executable property is used to control a versioned file's filesystem-level execute permission bit in a semi-automated way. This property has no defined values—its mere presence indicates a desire that the execute permission bit be kept enabled by Subversion. Removing this property will restore full control of the execute bit back to the operating system.

La proprietà svn:executable è usata per controllare i permessi di esecuzione di un file sotto controllo di versione in modo semi automatico . Questa proprietà non ha un valore definito; la sua presenza implica il desiderio che i diritti di esecuzione siano abilitati da Subversion. Rimuovendo questa proprietà si ridarà il controllo completo sui permessi di escuzione al sistema operativo.

On many operating systems, the ability to execute a file as a command is governed by the presence of an execute permission bit. This bit usually defaults to being disabled, and must be explicitly enabled by the user for each file that needs it. In a working copy, new files are being created all the time as new versions of existing files are received during an update. This means that you might enable the execute bit on a file, then update your working copy, and if that file was changed as part of the update, its execute bit might get disabled. So, Subversion provides the svn:executable property as a way to keep the execute bit enabled.

Su molti sistemi operativi, la possibilità di eseguire un file come un comando è governata dalla presenza di un bit di permesso di escuzione. Questo bit di solito di dafault è disabilitato, e deve essere esplicitamente abilitato dall'utente per ogni file che ne necessita. In una copia di lavoro, nuovi file vengono creati in ogni momento come nuove versioni di un file esistente oppure sono ricevuti durante un aggiornamento. Questo significa che che se si è abilitati a esguire il file,e poi si fa l'aggiornamento della propria copia di lavoro, e quel file ha subito delle modifiche, iil suo bit di esecuzione potrebbe essere disabilitato. Perciò, Subversion fornisce la proprietà svn:executable come un modo per conservare abilitato il bit di escuzione.

This property has no effect on filesystems that have no concept of an executable permission bit, such as FAT32 and NTFS. ^[52] Also, although it has no defined values, Subversion will force its value to * when setting this property. Finally, this property is valid only on files, not on directories.

Questa proprietà non ha effetti su filesystem che non hanno il concetto del bit per i permessi di esecuzione , come FAT32 e NTFS. ^[53] Inoltre,anche se non ha valori definiti, Subversion forzerà il suo valore a *quando si setta questa proprietà. Infine, questa proprietà è valida solo per i file, non per le directory.

The svn:mime-type property serves many purposes in Subversion. Besides being a general-purpose storage location for a file's Multipurpose Internet Mail Extensions (MIME) classification, the value of this property determines some behavioral characteristics of Subversion itself.

La proprietà svn:mime-type serve a diversi scopi in Subversion. Oltre ad essere una locazione per uso generale per la classificazione dei file Multipurpose Internet Mail Extensions (MIME) , il suo valore determina alcune caratteristiche comportamentali dello stesso Subversion .

For example, if a file's svn:mime-type property is set to a non-text MIME type (generally, something that doesn't begin with text/, though there are exceptions), Subversion will assume that the file contains binary—that is, not human-readable—data. One of the benefits that Subversion typically provides is contextual, line-based merging of changes received from the server during an update into your working file. But for files believed to contain binary data, there is no concept of a “line”. So, for those files, Subversion does not attempt to perform contextual merges during updates. Instead, any time you have locally modified a binary working copy file that is also being updated, your file is renamed with a .orig extension, and then Subversion stores a new working copy file that contains the changes received during the update, but not your own local modifications, at the original filename. This behavior is really for the protection of the user against failed attempts at performing contextual merges on files that simply cannot be contextually merged.

Ad esempio, se la proprietà di un file svn:mime-type è settata come tipo non-text MIME (generalmente, qualcosa che non inizia con text/, anche se ci sono delle eccezioni), Subversion assumerà che il file contiene valori binari—che sono dati , non leggibili—dall'uomo. Uno dei benefici che Subversion tipicamente fornisce è il merge contestuale, lined-based delle modifche ricevute dal server durante un update nel proprio file di lavoro. Ma per i file che si ritiene contengano dati binari, non c'è il concetto di «line». Così, per questi file, Subversion non fornisce merge contestuali durente l'update. Invece, ogni volta che viene modificato localmente la copia di lavoro di un file binario che è stato anche aggiornato,il file viene rinominato con un'estensione .orig , e quindi Subversion memorizza una nuova copia del file che contiene le modifiche ricevute durante l' update, ma non le modifiche fatte localmente, al file originale. Questo comportamento protegge l'utente contro i tentativi falliti di far confluire contestualemnte file che semplicemente non possono essere fusi contestualmente.

Also, if the svn:mime-type property is set, then the Subversion Apache module will use its value to populate the Content-type: HTTP header when responding to GET requests. This gives a crucial clue about how to display a file when perusing your repository with a web browser.

Inoltre , se è settata la proprietà svn:mime-type il modulo Apache di Subversion userà il suo valore per popolare Content-type: l'intestazione HTTP quando risponde a richieste ricevute .Questo fornisce una indicazione cruciale su come mostrare un file quando si ricerca in rete il proprio repository con un browser web.

The svn:ignore property contains a list of file patterns which certain Subversion operations will ignore. Perhaps the most commonly used special property, it works in conjunction with the global-ignores run-time configuration option (see sezione chiamata «Config») to filter unversioned files and directories out of commands svn status, svn add, and svn import.

La proprietà svn:ignore contiene una lista di percorsi di file che le operazioni di Subversion ignoreranno. Forse la proprietà speciale più comunemente usata lavora insieme all'opzione di configurazione fatta in fase di esecuzione global-ignores (si veda sezione chiamata «Config») per filtrare file che non sono sotto il controllo di versione e directory non incluse nei comandi svn status, svn add, and svn import.

The rationale behind the svn:ignore property is easily explained. Subversion does not assume that every file or subdirectory in a working copy directory is intended for version control. Resources must be explicitly placed under Subversion's management using the svn add or svn import commands. As a result, there are often many resources in a working copy that are not versioned.

Il motivo della proprietà svn:ignore è facilmente spiegato. Subversion non assume che ogni file o subdirectory presenti in una copia di lavoro siano sotto controllo di versione. Le risorse devono essere esplicitamente poste sotto il controllo di Subversion utilizzando il comnado svn add oppure il comando svn import. Come conseguenza, ci sono spesso molte risorse in una copia di lavoro che non sono sotto controllo di versione.

Now, the svn status command displays as part of its output every unversioned file or subdirectory in a working copy that is not already filtered out by the global-ignores option (or its built-in default value). This is done so that users can see if perhaps they've forgotten to add a resource to version control.

Ora, il comando svn status mostra come parte del suo output tutti i file o le subdirectory presenti in una copia di lavoro che non sono ancora stati filtrati dall'opzione global-ignores (oppure che sono incorporati nel valore di default). Questo è fatto affinchè gli utenti possano vedere se hanno dimenticato di aggiungere una risorsa al controllo di versione.

But Subversion cannot possibly guess the names of every resource that should be ignored. Also, quite often there are things that should be ignored in every working copy of a particular repository. To force every user of that repository to add patterns for those resources to their run-time configuration areas would be not just a burden, but has the potential to clash with the configuration needs of other working copies that the user has checked out.

Ma Subversion non ha la possibilità di ospitare i nomi di tutte le risorse che possono essere ignorate. Inoltre, piuttosto spesso ci sono cose che devono essere ignorate in ogni cartella di lavoro di un particolare repository. Costringere ogni utente del repository ad aggiungere i percorsi di queste risorse nella loro area di configurazione non è solo pesante , ma può causare anche un potenziale conflitto con le esigenze di configurazione di copie di lavoro di altri che l'utente ha aggiornato.

The solution is to store ignore patterns that are unique to the resources likely to appear in a given directory with the directory itself. Common examples of unversioned resources that are basically unique to a directory, yet likely to appear there, include output from program compilations. Or—to use an example more appropriate to this book—the HTML, PDF, or PostScript files generated as the result of a conversion of some source DocBook XML files to a more legible output format.

La soluzione è memorizzare i modellida ignorare che siano unici così come appare in una data directory con la directory stessa. Esempi comuni di risorse non revisionate che sono fondamentalmente uniche in una directory, sono forniti da output provenienti dalla compilazione di programmi. Oppure—per usare un esempio più appropriato per questo libro—i file HTML, PDF, o PostScript generati come risultato di una conversione di alcuni file sorgenti DocBook XML in un formato output più facilemnte leggibile.

$ svn propset svn:ignore -F .cvsignore .
property 'svn:ignore' set on '.'
$

For this purpose, the svn:ignore property is the solution. Its value is a multi-line collection of file patterns, one pattern per line. The property is set on the directory in which you wish the patterns to be applied. ^[54] For example, say you have the following output from svn status:

A tale scopo, la proprietà svn:ignore è la soluzione. Il suo valore è una collezione a righe multiple di modelli di file , un modello per linea. La proprietà è settata nella directory nella quale si desidera che i modelli vengano applicati. ^[55] Ad esempio supponiamo di avere il seguente output dal comando svn status:

$ svn status calc
 M     calc/button.c
?      calc/calculator
?      calc/data.c
?      calc/debug_log
?      calc/debug_log.1
?      calc/debug_log.2.gz
?      calc/debug_log.3.gz

In this example, you have made some property modifications to button.c, but in your working copy you also have some unversioned files: the latest calculator program that you've compiled from your source code, a source file named data.c, and a set of debugging output log files. Now, you know that your build system always results in the calculator program being generated. ^[56] And you know that your test suite always leaves those debugging log files lying around. These facts are true for all working copies, not just your own. And you know that you aren't interested in seeing those things every time you run svn status. So you use svn propedit svn:ignore calc to add some ignore patterns to the calc directory. For example, you might add this as the new value of the svn:ignore property:

In questo esempio, sono state effettuate alcune modifiche alla proprietà button.c, ma nella propria copia di lavoro ci sono anche alcuni file che non sono sotto controllo di versione: l'ultimo programma calculator che è stato compilato dal codice sorgente,un file sorgente chiamato data.c,e un insieme di file di log con l'output del debug. Ora, si sa che il sistema costruito risulta sempre nel programma che è stato generato calculator. ^[57] E si sa che la piattaforma di test lascia sempre questi file di log in giro. Questo è vero per ciascuna copia di lavoro, non soltanto per la propria. E si sa che non si ha alcun interesse nel vedere queste cose ogni volta che si esegue il comando svn status. Così si usa il comando svn propedit svn:ignore calc per aggiungere alcuni modelli da ignorare alla directory calc. Ad esempio, si può aggiungere questo come nuovo valore dalla proprietà svn:ignore:

calculator
debug_log*

After you've added this property, you will now have a local property modification on the calc directory. But notice what else is different about your svn status output:

Dopo che si è aggiunta questa proprietà,si avrà una modifica locale nella directory calc. Ma si noti cos'altro è diverso rispetto all'output del comando svn status :

$ svn status
 M     calc
 M     calc/button.c
?      calc/data.c

Now, all the cruft is missing from the output! Of course, those files are still in your working copy. Subversion is simply not reminding you that they are present and unversioned. And now with all the trivial noise removed from the display, you are left with more interesting items—such as that source code file that you probably forgot to add to version control.

Ora, tutti i file di log mancano! Naturalmente, questi file sono ancora nella propria copia di lavoro. Subversion semplicemnte non mostra che essi sono presenti e non sono sotot controllo di versione. E ora che tutti questi disturbi di poco conto sono stati rimossi dalla visualizzazione, si resta con oggetti—più interessanti;come il file sorgente che probabilmente si è dimenticato di aggiungere al controllo di versione.

If you want to see the ignored files, you can pass the --no-ignore option to Subversion:

Se si vogliono vedere i file ignorati, si può usare l'opzione --no-ignore di Subversion:

$ svn status --no-ignore
 M     calc/button.c
I      calc/calculator
?      calc/data.c
I      calc/debug_log
I      calc/debug_log.1
I      calc/debug_log.2.gz
I      calc/debug_log.3.gz

The list of patterns to ignore is also used by svn add and svn import. Both of these operations involve asking Subversion to begin managing some set of files and directories. Rather than force the user to pick and choose which files in a tree she wishes to start versioning, Subversion uses the ignore patterns to determine which files should not be swept into the version control system as part of a larger recursive addition or import operation.

La lista dei modelli da ignorare è usata anche dai comandi svn add e svn import. Entrambe queste operazioni implicano il richiedere a Subversion di gestire alcuni insiemi di file e directory. Piuttosto che costringere l'utente a scegliere quali file devono essere messi sotto il controllo di versione, Subversion usa i modelli da ignorare per determinare quali file non devono essere messi sotto controllo di versione come parte di un'operazione ricorsiva di aggiunta o di importazione.

Subversion has the ability to substitute keywords—pieces of useful, dynamic information about a versioned file—into the contents of the file itself. Keywords generally describe information about the last time the file was known to be modified. Because this information changes each time the file changes, and more importantly, just after the file changes, it is a hassle for any process except the version control system to keep the data completely up-to-date. Left to human authors, the information would inevitably grow stale.

Subversion ha la capacità di sostituire le parolechiave—informazione utile, dinamica su file—sotto controllo di versione;all'interno del file stesso. Le parole chiave generalmente descrivono informazioni sull'ultima volta che il file è stato modificato. Poichè questa informazione cambia ad ogni istante il file cambia e, each time the cosa più importante, solo dopo che il file è cambiato,esso crea un disturbo ad ogni processo eccetto al sistema sotto controllo di versione per mantenere la data aggiornata. L'informazione diventa inevitabilmente vecchia.

For example, say you have a document in which you would like to display the last date on which it was modified. You could burden every author of that document to, just before committing their changes, also tweak the part of the document that describes when it was last changed. But sooner or later, someone would forget to do that. Instead simply ask Subversion to perform keyword substitution on the LastChangedDate keyword. You control where the keyword is inserted into your document by placing a keyword anchor at the desired location in the file. This anchor is just a string of text formatted as $KeywordName$.

Ad esempio, supponimao di avere un documento nel quale si vuole visualizzare la data in cui è stato modificato. Si potrebbe costringere ogni autore di quel documento a modificare la parte di documento che descrive quando è stato modificato, subito prima di effettuare il commit delle modifiche. Ma prima o poi, qualcuno si dimenticherà di farlo. Invece semplicemente si chiede a Subversion di effettuare la sostituzione della chiave sulla DataUltimaModifica . Si controlla dove la chiave è inserita all'interno del documento mettendo una ancora chiave nel punto desiderato del file. Quest'ancora è semplicemente una stringa di testo formattata in questo modo $Nome chiave$.

All keywords are case-sensitive where they appear as anchors in files: you must use the correct capitalization in order for the keyword to be expanded. You should consider the value of the svn:keywords property to be case-sensitive too—certain keyword names will be recognized regardless of case, but this behavior is deprecated.

Tutte le chiavi sono case-sensitive quando appaiono come ancore nei file: bisogna usare la corretta scrittura in maiuscolo perchè le chiavi possano essere diffuse. Bisogna considerare il valore della proprietà svn:keywords anch'essa case-sensitive;alcuni nomi di chiavi vengono riconosciuti indipendentemente dal carattere,ma questo comportamento è deprecato.

Subversion defines the list of keywords available for substitution. That list contains the following five keywords, some of which have aliases that you can also use:

Subversion definisce la lista di chiavi che possono essere sostituite. Questa lista contiene le seguenti cinque chiavi, alcune delle quali sono alias che si possono usare:

Simply adding keyword anchor text to your file does nothing special. Subversion will never attempt to perform textual substitutions on your file contents unless explicitly asked to do so. After all, you might be writing a document ^[58] about how to use keywords, and you don't want Subversion to substitute your beautiful examples of un-substituted keyword anchors!

Aggiungere semplicemente delle chiavi ancora ai propri file non comporta niente di speciale. Subversion non provvederà mai ad effettuare sostituzioni testuali sui contenuti di un file senza che sia richiesto esplicitamente. Dopo tutto,si potrebbe aver scritto un documento ^[59] su come usare le chiavi, e certo non si vorrebbe che Subversion sostituisse i propri esempi belli con le chiavi ancora!

To tell Subversion whether or not to substitute keywords on a particular file, we again turn to the property-related subcommands. The svn:keywords property, when set on a versioned file, controls which keywords will be substituted on that file. The value is a space-delimited list of the keyword names or aliases found in the previous table.

Per dire a Subversion se sostituire o meno le chiavi di un particolare file, bisogna tornare sui sottocomandi collegati alle proprietà. La proprietà svn:keywords , quando settata su un file sotto controllo di versione, controlla quali chiavi dovranno essere sostituite su quel file. Il valore è una lista delimitata da spazi di nomi di chiavi o alias trovati nella precedente tabella.

For example, say you have a versioned file named weather.txt that looks like this:

Ad esempio, si supponga di avere un file sotto controllo di versione chiamato weather.txt che ha questa forma:

Here is the latest report from the front lines.
$LastChangedDate$
$Rev$
Cumulus clouds are appearing more frequently as summer approaches.

With no svn:keywords property set on that file, Subversion will do nothing special. Now, let's enable substitution of the LastChangedDate keyword.

Senza la proprietà svn:keywords settata su quel file, Subversionnon farà niente di speciale. Ora, si abiliti la sostituzione della chiave LastChangedDate.

$ svn propset svn:keywords "Date Author" weather.txt
property 'svn:keywords' set on 'weather.txt'
$

Now you have made a local property modification on the weather.txt file. You will see no changes to the file's contents (unless you made some of your own prior to setting the property). Notice that the file contained a keyword anchor for the Rev keyword, yet we did not include that keyword in the property value we set. Subversion will happily ignore requests to substitute keywords that are not present in the file, and will not substitute keywords that are not present in the svn:keywords property value.

A questo punto è stata fatta una modifica locale sul file weather.txt . Non si vedranno cambiamenti sui contenuti del file (a meno che non ne sia stato fatto qualcuno prima per settare la proprietà). Si noti che il file conteneva un ancora chiave per la chiave Rev, non è ancora stata inclusa quella chiave nel valore settato alla proprietà. Subversion ignorerà le richieste di sostituire chiavi che non sono presenti nel file, e non sostituirà chiavi che non sono presenti nel valore della proprietà svn:keywords.

Immediately after you commit this property change, Subversion will update your working file with the new substitute text. Instead of seeing your keyword anchor $LastChangedDate$, you'll see its substituted result. That result also contains the name of the keyword, and continues to be bounded by the dollar sign ($) characters. And as we predicted, the Rev keyword was not substituted because we didn't ask for it to be.

Subito dopo il commit questa propretà cambia, Subversion aggiornerà il file di lavoro con il nuovo testo. Invece di vedere la propria parola chiave ancora, $LastChangedDate$, si vedrà la sua sostituzione. Questo risultato contiene anche il nome della chiave, e continua ad essere delimitata dal simbolo del dollaro ($) . Come è stato predetto, la chiave Rev non è stata sostituita perchè non è stato richiesto espressamente di farlo.

Note also that we set the svn:keywords property to “Date Author” yet the keyword anchor used the alias $LastChangedDate$ and still expanded correctly.

Si noti anche che la proprietà svn:keywords è stata settata a «Date Author» la chiave ancora usa l'alias $LastChangedDate$ ed è ancora ampliata correttamente.

Here is the latest report from the front lines.
$LastChangedDate: 2002-07-22 21:42:37 -0700 (Mon, 22 Jul 2002) $
$Rev$
Cumulus clouds are appearing more frequently as summer approaches.

If someone else now commits a change to weather.txt, your copy of that file will continue to display the same substituted keyword value as before—until you update your working copy. At that time the keywords in your weather.txt file will be re-substituted with information that reflects the most recent known commit to that file.

Se qualcun altro adesso fa il commit di una modifica al file weather.txt, la propria copia del file continuerà a mostrare gli stessi valoridelle chiavi sostituite come prima—finchè non si aggiorna la propria copia. In quel momento la chiave nella propria copia del file weather.txt verrà risostiutita con informazioni che riflettono il commit più recente conosciuto per quel file.

Subversion 1.2 introduced a new variant of the keyword syntax which brought additional, useful—though perhaps atypical—functionality. You can now tell Subversion to maintain a fixed length (in terms of the number of bytes consumed) for the substituted keyword. By using a double-colon (::) after the keyword name, followed by a number of space characters, you define that fixed width. When Subversion goes to substitute your keyword for the keyword and its value, it will essentially replace only those space characters, leaving the overall width of the keyword field unchanged. If the substituted value is shorter than the defined field width, there will be extra padding characters (spaces) at the end of the substituted field; if it is too long, it is truncated with a special hash (#) character just before the final dollar sign terminator.

Subversion 1.2 ha introdotto una nuova variante della sintassi delle chiavi che apporta funzionalità aggiuntive, utili—anche se forse atipiche. Adesso si può dire a Subversion di mantenere una lunghezza fissata(in termini di numero di byte usati) per le chiavi sostiutite. Usando una coppia di due punti (::) dopo il nome della chiave, seguita da un numero di spazi, si definisce la dimensione fissata. Quando Subversion va a sostituire la propria chiave con la chiave e il suo valore, essenzialmente sostituisce solo questi spazi, lasciando complessivamente invariata la la dimensione del campo. Se il valore sostituito è più corto , saranno aggiunti caratteri di riempimento (spazi) alla fine del campo sostituito; se è troppo lungo, sarà troncato con un carattere speciale (#) prima del simbolo di dollaro di chiusura.

For example, say you have a document in which you have some section of tabular data reflecting the document's Subversion keywords. Using the original Subversion keyword substitution syntax, your file might look something like:

Ad esempio, si supponga di avere un documento nel quale si ha una sezione di dati tabulare che riflette le chiavi di Subversion . Usando la sintassi originale di sostituzione della chiave di Subversion , il file assume questo aspetto:

$Rev$:     Revision of last commit
$Author$:  Author of last commit
$Date$:    Date of last commit

Now, that looks nice and tabular at the start of things. But when you then commit that file (with keyword substitution enabled, of course), you see:

Adesso, sembra bello e tabulare . Ma quando si fa il commit del file (naturalmente con la sostituzione della chiave abilitata), si vedrà:

$Rev: 12 $:     Revision of last commit
$Author: harry $:  Author of last commit
$Date: 2006-03-15 02:33:03 -0500 (Wed, 15 Mar 2006) $:    Date of last commit

The result is not so beautiful. And you might be tempted to then adjust the file after the substitution so that it again looks tabular. But that only holds as long as the keyword values are the same width. If the last committed revision rolls into a new place value (say, from 99 to 100), or if another person with a longer username commits the file, stuff gets all crooked again. However, if you are using Subversion 1.2 or better, you can use the new fixed-length keyword syntax, define some field widths that seem sane, and now your file might look like this:

Questo risultato non è così bello. E si potrebbe essere tentati ad aggiustare il file dopo la sostituzione cosicchè torni ad essere tabulare. Ma questo vale soltanto se i valori delle chiavi hanno la stessa dimensione. Se l'ultima revisione di cui si è fatto il commit si sposta in un nuovo valore (ad esempio, da 99 a 100), o un'altra persona con uno username più lungo fa il commit del file, le cose si mettono male nuovamente. Comunque, se si sta usando Subversion 1.2 o più avanzate, si può usare la sintassi dei valori di lunghezza fissata, definire alcune dimensioni di campi che sembrino giusti, e a questo punto il file avrà questo aspetto:

$Rev::               $:  Revision of last commit
$Author::            $:  Author of last commit
$Date::              $:  Date of last commit

You commit this change to your file. This time, Subversion notices the new fixed-length keyword syntax, and maintains the width of the fields as defined by the padding you placed between the double-colon and the trailing dollar sign. After substitution, the width of the fields is completely unchanged—the short values for Rev and Author are padded with spaces, and the long Date field is truncated by a hash character:

Si fa il commit di questa modifica sul proprio file.Questa volta, Subversion si accorge della nuova sintassi della chiave che fissa la lunghezza, e mantiene la larghezza dei campi com'è definita dal rivestimento inserito tra la colonna doppia e il simbolo del dollaro. Dopo la sostituzione, la larghezza dei campi è completamente invariata—i valori brevi per Rev e Author sono imbottiti con spazi, e il campo della Date è troncato da un carattere hash :

$Rev:: 13            $:  Revision of last commit
$Author:: harry      $:  Author of last commit
$Date:: 2006-03-15 0#$:  Date of last commit

The use of fixed-length keywords is especially handy when performing substitutions into complex file formats that themselves use fixed-length fields for data, or for which the stored size of a given data field is overbearingly difficult to modify from outside the format's native application (such as for Microsoft Office documents).

L'uso delle chiavi di lunghezza fissata è molto pratico soprattutto quando si effettuano sostituzioni in un file complesso che già usa campi di lunghezza fissata per i dati, o per il quale la dimensione per la memorizzazione di un dato è difficile da modificare dall'esterno dell'applicazione (come ad esempio per i documenti Microsoft Office ).

Avvertimento

Be aware that because the width of a keyword field is measured in bytes, the potential for corruption of multi-byte values exists. For example, a username which contains some multi-byte UTF-8 characters might suffer truncation in the middle of the string of bytes which make up one of those characters. The result will be a mere truncation when viewed at the byte level, but will likely appear as a string with an incorrect or garbled final character when viewed as UTF-8 text. It is conceivable that certain applications, when asked to load the file, would notice the broken UTF-8 text and deem the entire file corrupt, refusing to operate on the file altogether. Bisogna prestare attenzione a questa cosa poichè lalarghezza di un campo chiave è misurata in bytes, e quindi esiste la possibilità di corruzione per i valori multi-byte. Ad esempio, uno username che contiene alcuni caratteri multi-byte UTF-8 potrebbe risentire dell'interruzione nel mezzo di una stringa di bytes quale quella fatta da uno di questi caratteri. Il risultato sarà uno spezzamento visto a livello di byte, ma apparirà come una stringa con un carattere finale errato o alterato quando si guarda il testo UTF-8. E' immaginabile che certe applicazioni, quando si chiede di caricare il file, notano il testo UTF-8 rotto e considerano corrotto l'intero file, rifiutando completamente di operare su quel file.

Unless otherwise noted using a versioned file's svn:mime-type property, Subversion assumes the file contains human-readable data. Generally speaking, Subversion only uses this knowledge to determine if contextual difference reports for that file are possible. Otherwise, to Subversion, bytes are bytes.

Se non diversamente notato usando la proprietà svn:mime-typedi un file sotto versione, Subversion assume che il file contiene dati leggibili dall'uomo. Parlando in generale, Subversion usa questa conoscenza per determinare se per quel file sono possibili differenze contestuali. In caso contrario, per Subversion, bytes sono bytes.

This means that by default, Subversion doesn't pay any attention to the type of end-of-line (EOL) markers used in your files. Unfortunately, different operating systems use different tokens to represent the end of a line of text in a file. For example, the usual line ending token used by software on the Windows platform is a pair of ASCII control characters—carriage return (CR) and line feed (LF). Unix software, however, just uses the LF character to denote the end of a line.

Questo significa che di default, Subversion non presta nessuna attenzione al tipo di marcatori end-of-line (EOL) usati nei propri file. Sfortunamente, diversi sistemi operativi usano diversi segni per rappresentare la fine di una linea del testo in un file.Ad esempio, il segno di fine linea di solito usato dal software della piattaforma Windows è una coppia di caratteri—di controllo ASCII ; il tasto return (CR) e (LF). I software Unix, tuttavia, usano soltanto il carattere LF per indicare la fine della linea.

Not all of the various tools on these operating systems are prepared to understand files that contain line endings in a format that differs from the native line ending style of the operating system on which they are running. Common results are that Unix programs treat the CR character present in Windows files as a regular character (usually rendered as ^M), and that Windows programs combine all of the lines of a Unix file into one giant line because no carriage return-linefeed (or CRLF) character combination was found to denote the end of line.

Non tutti i varo tool di questi sistemi operativi sono preparati a capire file che contengono indicatori di fine di linea in un formato che differisce dallo stile nativo di fine linea del sistema operativo sul quale vengono eseguiti. Risultati comuni sono che i programmi Unix trattano il carattere CR presente nei file Windows come un carattere regolare (di solito trattato come ^M), e che i programmi Windows combinano tutte le linee di un file Unixin una sola gigante linea perchè non ci sono caratteri di fine linea ( CRLF).

This sensitivity to foreign EOL markers can become frustrating for folks who share a file across different operating systems. For example, consider a source code file, and developers that edit this file on both Windows and Unix systems. If all the developers always use tools which preserve the line ending style of the file, no problems occur.

Questa sensibilità ai marcatori esterni di EOL può diventare frustrante per persone che condividono un file su diversi sistemi operativi. Ad esempio, si consideri un file di codice sorgente, e gli sviluppatori che modificano questo file su entrmbi i sistemi Windows e Unix . Se tutti gli sviluppatori usano sempre tool che conservano lo stile di fine linea del file, non si genera nessun problema.

But in practice, many common tools either fail to properly read a file with foreign EOL markers, or they convert the file's line endings to the native style when the file is saved. If the former is true for a developer, he has to use an external conversion utility (such as dos2unix or its companion, unix2dos) to prepare the file for editing. The latter case requires no extra preparation. But both cases result in a file that differs from the original quite literally on every line! Prior to committing his changes, the user has two choices. Either he can use a conversion utility to restore the modified file to the same line ending style that it was in before his edits were made. Or, he can simply commit the file—new EOL markers and all.

Ma in pratica, i più comuni tool o falliscono nel leggere un file con marcatori EOL esterni, o convertono la fine della linea nello stile nativo quando il file è salvato. Se il primo è vero per uno sviluppatore, egli dovrà usare una conversione esterna (come dos2unix o il suo compagno, unix2dos) per preparare il file per la modifica. Il secondo caso non richiede preparazione extra. Ma in entrambi i casi il risultato è un file che differisce dall'originale molto letteralmente su ogni linea! Prima di committare le proprie modifiche, l'utente ha due scelte. Può usare una conversione per reintegrare il file modificato con lo stesso stile di eol che aveva prima che egli facesse le sue modifiche. Oppure, può semplicemente committare il file—nuovi marcatori EOL e tutto.

The result of scenarios like these include wasted time and unnecessary modifications to committed files. Wasted time is painful enough. But when commits change every line in a file, this complicates the job of determining which of those lines were changed in a non-trivial way. Where was that bug really fixed? On what line was a syntax error introduced?

Il risultato di scenari come questi include perdita di tempo e modifiche non necessaria per committare i file. Già la perdita di tempo è abbastanza dolorosa. Ma quando si fa il commit di modifiche su ogni linea del file, questo complica il lavoro per determinare quale di quelle linee sono state modificate in modo non significativo. Dov'è realmente fissato il bug ? Su quale linea c'è un errore di sintassi?

The solution to this problem is the svn:eol-style property. When this property is set to a valid value, Subversion uses it to determine what special processing to perform on the file so that the file's line ending style isn't flip-flopping with every commit that comes from a different operating system. The valid values are:

La soluzione a questo problema è la proprietà svn:eol-style.Quando questa proprietà è settata ad un valore valido, Subversion la usa per determinare quale lvorazione speciale deve essere fatta sul file per fare in modo che lo stile di fine linea del file non oscilli con ogni commit che viene fatto da un diverso sistema operativo. I valori validi sono:

The svn:externals property contains instructions for Subversion to populate a versioned directory with one or more other checked-out Subversion working copies. For more information on this keyword and its use, see sezione chiamata «Externals Definitions».

La proprietà svn:externals contiene istruzioni per far popolare da Subversion to populate una directory sotto controllo di versione con una o più copie di lavoro di cui si è fatto il check-out. Per maggiori informazioni su questa chiave e il suo uso, si veda sezione chiamata «Externals Definitions».

The svn:special property is the only svn: property that isn't meant to be directly set or modified by users. Subversion automatically sets this property whenever a “special” object is scheduled for addition, such as a symbolic link. The repository stores an svn:special object as an ordinary file. However, when a client sees this property during checkouts or updates, it interprets the contents of the file and translates the item back into the special type of object. In versions of Subversion current at the time of writing, only versioned symbolic links have this property attached, but in future versions of Subversion other special types of nodes will probably use this property as well.

La proprietà svn:specialè l'unica proprietà svn: che non può essere direttamente settata o modificata dagli utenti. Subversion setta automaticamente questa proprietà ogni volta che si vuole aggiungere un oggetto «speciale», come ad esempio, un link simbolico. Il repository immagazzina un oggettosvn:special come un file ordinario. Comunque, quando un client vede questa proprietà durante il check out per l'aggiornamento, esso interpreta il contenuto del file e riporta l'oggetto nel suo tipo speciale. Nelle versioni di Subversion che ci sono al momento in cui si sta scrivendo, soltanto i colelgamenti simbolici sotto controllo di versione hanno allegata questa proprietà, ma in futuro, nelle nuove versioni di Subversion, altri speciali tipi di nodi probabilmente useranno questa proprietà altrettanto bene.

Note: Windows clients don't have symbolic links, and thus ignore any svn:special files coming from a repository that claim to be symbolic links. On Windows, the user ends up with an ordinary versioned file in the working copy.

Nota: i client Windows non hanno collegamenti simbolici, and perciò ignorano tutti i file svn:special che vengono da un repository e che pretendono di essere collegamenti simbolici. Su Windows, l'utente finisce con un file ordinario sotto controllo di versione nella cartella di lavoro.

This property is used to signify that the file it's attached to ought to be locked before editing. The value of the property is irrelevant; Subversion will normalize its value to *. When present, the file will be read-only unless the user has explicitly locked the file. When a lock-token is present (as a result of running svn lock), the file becomes read-write. When the lock is released, the file becomes read-only again.

Questa proprietà è usata per indicare che il file a cui è allegata è bloccato prima della modifica. Il valore della proprietà è irrilevante; Subversion normalizzerà il suo valore a *. Se presente, il file sarà di sola lettura a meno che l'utente non abbia esplicitamente bloccato il file. Se è presente un simbolo di blocco (come sirultato di un comando svn lock), il file diventa leggibile e scrivibile. Quando il blocco viene tolto, il file diventa di nuovo di sola lettura.

To learn more about how, when, and why this property should be used, see sezione chiamata «Lock Communication».

Per saperne di più su come, quando e perchè questa proprietà dovrebbe essere usata, si veda sezione chiamata «Lock Communication».