Merging changes sounds simple enough, but in practice it can become a headache. The problem is that if you repeatedly merge changes from one branch to another, you might accidentally merge the same change twice. When this happens, sometimes things will work fine. When patching a file, Subversion typically notices if the file already has the change, and does nothing. But if the already-existing change has been modified in any way, you'll get a conflict.

Fondere modifiche suona abbastanza semplice, ma in prattica può diventare mal di testa. Il problema è che se ripetutamente fondete modifiche da un ramo ad altro, potete accidentalmente fondere la stessa modifica due volte. Se succede questo, a volte tutto va bene. Quando Subversion applica le modifiche su un file, tipicamente si accorge che il file queste modifiche ha già e non fa niente. Ma se la già esistente modifica era ulteriormente modificata, otente un conflitto.

Ideally, your version control system should prevent the double-application of changes to a branch. It should automatically remember which changes a branch has already received, and be able to list them for you. It should use this information to help automate merges as much as possible.

Idealmente, vostro sistema di controlo delle versioni dovrebbe prevenire la doppia applicazione delle modifiche su un ramo. Dovrebbe automaticamente ricordare quale modifiche il ramo ha già ricevuto ed essere capace di elencarle per voi. Dovrebbe usare queste informazioni per automatizzare le fusioni quanto più possibile.

Unfortunately, Subversion is not such a system. Like CVS, Subversion does not yet record any information about merge operations. When you commit local modifications, the repository has no idea whether those changes came from running svn merge, or from just hand-editing the files.

Sfortunatamente, un sistema così non è Subversion. Come il CVS, Subversion non memorizza ancora nessuna informazione riguardo operazioni di fusioni. Quando fatte commit delle modifiche locali, il deposito(repository) non ha idea se queste modifiche arrivano da svn merge eseguito o da editazione a mano dei file.

What does this mean to you, the user? It means that until the day Subversion grows this feature, you'll have to track merge information yourself. The best place to do this is in the commit log-message. As demonstrated in the earlier example, it's recommended that your log-message mention a specific revision number (or range of revisions) that are being merged into your branch. Later on, you can run svn log to review which changes your branch already contains. This will allow you to carefully construct a subsequent svn merge command that won't be redundant with previously ported changes.

Che cosa significa questo per voi, utente? Significa che fino al giorno in cui Subversion avrà questa capacità, dovete tracciare informazioni riguardo le fusioni da soli. Il posto migliore dove farlo è messaggio di commit. Come era dimostrato nel esempio precedente, è raccomandato che vostro messaggio menziona specifico numero della revisione (o rango delle revisioni) che state fondendo nel vostro ramo. In futuro potete avviare comando svn log per vedere quale modifiche contiene già il vostro ramo. Questo vi permete di costruire con cura prossimi comandi svn merge che non saranno redundanti con le modifiche già riportate in precedenza.

In the next section, we'll show some examples of this technique in action.

Nella prossima sezione mostreremo in azione alcuni esempi di questa tecnica.

Because merging only results in local modifications, it's not usually a high-risk operation. If you get the merge wrong the first time, simply svn revert the changes and try again.

Perché risultato delle fusioni sono soltanto le modifiche locali, questa non è normalmente una operazione ad alto rischio. Se vi capita di fondere male prima volta, semplicemente buttate via le modifiche (svn revert) e provate di nuovo.

It's possible, however, that your working copy might already have local modifications. The changes applied by a merge will be mixed with your pre-existing ones, and running svn revert is no longer an option. The two sets of changes may be impossible to separate.

È possibile, comunque, che vostra copia di lavoro contiene anche le modifiche locali. Le modifiche applicate da merge saranno mischiate tra le vostre e avviare comando svn revert non è più una scelta pratticabile. Potrebbe essere impossibile separare i due insiemi delle modifiche.

In cases like this, people take comfort in being able to predict or examine merges before they happen. One simple way to do that is to run svn diff with the same arguments you plan to pass to svn merge, as we already showed in our first example of merging. Another method of previewing is to pass the --dry-run option to the merge command:

In casi come questo, le persone si confortano con la possibilità di prevedere o esaminare fusione prima che accade. Un semplice modo per farlo è avviare svn diff con gli stessi argomenti che avete in mente di passare a svn merge, come abbiamo già mostrato nel nostro primo esempio. Altro metodo di anteprima è aggiungere la opzione --dry-run(a secco) al comando merge:

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

$ svn status
#  nothing printed, working copy is still unchanged.

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

  $ svn status
  # non stampa niente, copia di lavoro è ancora intatta.

The --dry-run option doesn't actually apply any local changes to the working copy. It only shows status codes that would be printed in a real merge. It's useful for getting a “high level” preview of the potential merge, for those times when running svn diff gives too much detail.

La opzione --dry-run in verità non applica nessuna modifica locale alla copia di lavoro. Mostra solo output che sarebbe mostrato con la fusione vera. Questo è utile per avere una previsione ad «alto livello» della potenziale fusione, per quelle volte dove comando svn diff dà troppi dettagli.

Just like the svn update command, svn merge applies changes to your working copy. And therefore it's also capable of creating conflicts. The conflicts produced by svn merge, however, are sometimes different, and this section explains those differences.

Così come comando svn update, anche svn merge applica modifiche alla vostra copia di lavoro. E perciò è capace generare conflitti. I conflitti prodotti da svn merge, tuttavia, sono a volte diversi e questa sezione spiega queste differenze.

To begin with, assume that your working copy has no local edits. When you svn update to a particular revision, the changes sent by the server will always apply “cleanly” to your working copy. The server produces the delta by comparing two trees: a virtual snapshot of your working copy, and the revision tree you're interested in. Because the left-hand side of the comparison is exactly equal to what you already have, the delta is guaranteed to correctly convert your working copy into the right-hand tree.

Per cominciare, si assume che vostra copia di lavoro non ha editazioni locali. Quando la aggiornate (svn update) ad una particolare versione, le modifiche mandate dal server si applicano sempre alla vostra copia di lavoro in modo «pulito». Il server produce un ??delta? comparando due strutture: un'instantanea virtuale della vostra copia di lavoro e struttura della revisione a quale siete interessati. Perché lato sinistra della comparazione è uguale a quel che già avete il delta garantisce di correttamente convertire vostra copia di lavoro nella struttura di lato destra.

But svn merge has no such guarantees and can be much more chaotic: the user can ask the server to compare any two trees at all, even ones that are unrelated to the working copy! This means there's large potential for human error. Users will sometimes compare the wrong two trees, creating a delta that doesn't apply cleanly. svn merge will do its best to apply as much of the delta as possible, but some parts may be impossible. Just like the Unix patch command sometimes complains about “failed hunks”, svn merge will complain about “skipped targets”:

Ma svn merge non ha tali garanzie e può essere più caotico: utente può chidere al server di comparare qualsiasi due strutture, anche tali che non hanno nessun legame con la copia di lavoro. Questo significa che qui c'è largo potenziale per errori umani. Utenti possono a volte comparare due strutture sbagliate, creando delta che non si applica pulitamente. svn merge farà il meglio per applicare più possibile il delta, ma su alcune parti questo potrà essere impossibile. Nello stesso modo come comando Unix patch a volte si lamenta di ??«failed hunks»?, svn merge può accusare «skipped targets» (destinazioni saltate):

$ svn merge -r 1288:1351 http://svn.example.com/repos/branch
U  foo.c
U  bar.c
Skipped missing target: 'baz.c'
U  glub.c
C  glorb.h

$

In the previous example it might be the case that baz.c exists in both snapshots of the branch being compared, and the resulting delta wants to change the file's contents, but the file doesn't exist in the working copy. Whatever the case, the “skipped” message means that the user is most likely comparing the wrong two trees; they're the classic sign of driver error. When this happens, it's easy to recursively revert all the changes created by the merge (svn revert --recursive), delete any unversioned files or directories left behind after the revert, and re-run svn merge with different arguments.

Nel esempio precedente può essere caso che baz.c esiste in entrambe instantanee del ramo comparato e delta risultante vuole cambiare il contenuto del file, ma il file non esiste nella copia di lavoro. Qualunque sia causa, il messaggio «skipped»(saltato) significa che con alta probabilità utente sta comparando le strutture sbagliate; questo è un segno classico del 'errore del conducente'. Quando accade ciò, è semplice invertire ricorsivamente tutte le modifiche create dalla fusione (svn revert --recursive), cancellare ogni file o cartella rimasta senza controllo delle versioni dopo revert e rifare svn merge con argomenti diversi.

Also notice that the previous example shows a conflict happening on glorb.h. We already stated that the working copy has no local edits: how can a conflict possibly happen? Again, because the user can use svn merge to define and apply any old delta to the working copy, that delta may contain textual changes that don't cleanly apply to a working file, even if the file has no local modifications.

Notare ancora che precedente esempio mostra un conflitto accaduto su glorb.h. Abbiamo già stabilito che copia di lavoro non ha editazioni locali: come può allora accadere un conflitto? Di nuovo, perché l'utente può usare svn merge per definire ed applicare qualsiasi delta vecchio a copia di lavoro, tale delta può contenere modifiche testuali che non si applicano in modo pulito al file di lavoro, anche se il file non ha le modifiche locali.

Another small difference between svn update and svn merge are the names of the full-text files created when a conflict happens. In sezione chiamata «Risolvere i conflitti(Mettere insieme i cambiamenti operati da altri)», we saw that an update produces files named filename.mine, filename.rOLDREV, and filename.rNEWREV. When svn merge produces a conflict, though, it creates three files named filename.working, filename.left, and filename.right. In this case, the terms “left” and “right” are describing which side of the double-tree comparison the file came from. In any case, these differing names will help you distinguish between conflicts that happened as a result of an update versus ones that happened as a result of a merge.

Altra piccola differenza tra svn update e svn merge sono i nomi dei file testuali creati quando accade un conflitto. Nella sezione chiamata «Risolvere i conflitti(Mettere insieme i cambiamenti operati da altri)», abbiamo visto che un aggiornamento (update) produce file nominati filename.mine, filename.rOLDREV e filename.rNEWREV. Quando comando svn merge produce un conflitto, ??though?, crea tre file nominati filename.working, filename.left e filename.right. Qui i termini «left» e «right» descrivono da quale lato della comparazione delle strutture proviene il file. In qualsiasi caso, questi nomi diversi vi aiuteranno distinguere tra conflitti che accadono come risultato d'un aggiornamento (update) e tali che accadono come risultato d'una fusione (merge).

When conversing with a Subversion developer, you might very likely hear reference to the term ancestry. This word is used to describe the relationship between two objects in a repository: if they're related to each other, then one object is said to be an ancestor of the other.

Parlando con sviluppatori di Subversion, uno può molto probabilmente sentire riferimento al termine ascendenza(ancestry). Questa parola è usata per descrivere la relazione tra due oggetti nel deposito(repository): se sono in relazione si dice che uno è antenato dell'altro.

For example, suppose you commit revision 100, which includes a change to a file foo.c. Then foo.c@99 is an “ancestor” of foo.c@100. On the other hand, suppose you commit the deletion of foo.c in revision 101, and then add a new file by the same name in revision 102. In this case, foo.c@99 and foo.c@102 may appear to be related (they have the same path), but in fact are completely different objects in the repository. They share no history or “ancestry”.

Per esempio, supponiamo che voi depositate la versione 100, che include una modifica a file foo.c. Dopo questo il file foo.c@99 è un «antenato» di foo.c@100. Caso oposto, supponiamo che depositate la cancellazione del foo.c nella versione 101 e dopo aggiugete nuovo file con lo stesso nome nella versione 102. In questo caso, foo.c@99 e foo.c@102 possono apparire in relazione (hanno lo stesso percorso e nome), ma in verità sono oggetti del deposito(repository) completamente diversi. Non condividono nessuna storia o «ascendenza».

The reason for bringing this up is to point out an important difference between svn diff and svn merge. The former command ignores ancestry, while the latter command is quite sensitive to it. For example, if you asked svn diff to compare revisions 99 and 102 of foo.c, you would see line-based diffs; the diff command is blindly comparing two paths. But if you asked svn merge to compare the same two objects, it would notice that they're unrelated and first attempt to delete the old file, then add the new file; the output would indicate a deletion followed by an add:

La ragione per spiegare questo è di puntare il dito sulla differenza importante tra svn diff e svn merge. Il primo comando ignora ascendenza, invece il secondo è assai sensibile ad essa. Per esempio, chiedendo a svn diff di comparare revisioni 99 e 102 di foo.c, potete vedere differenze basate sulle linee; il comando diff ciecamente compara i due file. Ma se chiedete a svn merge di comparare gli stessi oggetti, lui si accorge che non sono in relazione e prima provede a cancellare quello vecchio e poi aggiunge nuovo; output indicherà una cancellazione seguita da una aggiunta:

D  foo.c
A  foo.c

Most merges involve comparing trees that are ancestrally related to one another, and therefore svn merge defaults to this behavior. Occasionally, however, you may want the merge command to compare two unrelated trees. For example, you may have imported two source-code trees representing different vendor releases of a software project (see sezione chiamata «Vendor branches»). If you asked svn merge to compare the two trees, you'd see the entire first tree being deleted, followed by an add of the entire second tree!

Molte fusioni coinvolgono comparazioni delle strutture che sono genealogicamente relazionate tra loro, e perciò svn merge ha come predefinito questo comportamento. Occasionalmente, tuttavia, si può volere che comando merge compara due strutture che non sono in relazione. Per esempio, si può importare due strutture del codice sorgente che rappresentano due rilasci pubblici d'un progetto software (vedi la sezione chiamata «Vendor branches»). Chiedendo a svn merge di comparare queste due strutture, si vede prima la cancellazione completta della prima struttura, seguita da aggiunta di tutta la seconda struttura!

In these situations, you'll want svn merge to do a path-based comparison only, ignoring any relations between files and directories. Add the --ignore-ancestry option to your merge command, and it will behave just like svn diff. (And conversely, the --notice-ancestry option will cause svn diff to behave like the merge command.)

In tali situazioni, si chiede a svn merge di fare comparazione basata solo sui nomi, ignorando qualsiasi relazione tra i file e cartelle. Si aggiunge opzione --ignore-ancestry al vostro comando di fusione, e quello si comporterà esattamente come svn diff. (E al contrario, la opzione --notice-ancestry causerà che svn diff aggirà come comando merge.)