#language it

Il modello di sviluppo decentralizzato di Mercurial può risultare difficile da comprendere per i nuovi utenti. Questa pagina prova a illustrare alcuni dei concetti di base.

''(This page in English: UnderstandingMercurial)''

Vedi il [[Tutorial]] per istruzioni passo-passo.

<<TableOfContents>>

== Cosa c'è dentro un Repository ==

I Repository di Mercurial contengono una '''cartella di lavoro''' e uno '''store''':

{{{#!dot
digraph G {
 compound=true;
 rankdir = LR
 background="#999999";
 subgraph cluster_1 {
  style=filled;
  color="#eeeeee";
  node [shape=box,style=filled,color=lightgray];
  "rev 0" -> "rev 1" -> "rev 2" -> "rev 3";
  label = "store";
 }
 subgraph cluster_0 {
  style=filled;
  color=lightgrey;
  node [style=filled,color=white];
  edge [style=invis];
  "main.c"->  "main.h" ->  ".hgignore" ->  ".hgtags"
  label="cartella di lavoro";
 }
 "rev 2" -> ".hgtags" [lhead = cluster_0 constraint=false]
}
}}}

Lo store contiene la '''cronologia''' "completa" del progetto. Al contrario dei tradizionali SCM (Source Code Management, ossia Gestori di code sorgente), dove c'è solo una copia centrale della cronologia, ogni cartella di lavoro è associata ad una sua copia (privata) della cronologia. Questo permette allo sviluppo di '''procedere in parallelo'''.

La cartella di lavoro contiene una copia dei file del progetto ad un determinato momento (per es. revisione 2), pronti per la modifica. Dato che i tags e i file ignorati sono "revision-controlled", sono anch'essi inclusi.

== Effettuare Modifiche ==

Quando concludi delle modifiche, lo stato corrente della cartella di lavoro, relativamente alle revisioni precedenti, viene registrato come una nuova revisione.

{{{#!dot
digraph G {
 compound=true;
 rankdir = LR
 background="#999999";
 subgraph cluster_1 {
  style=filled;
  color="#eeeeee";
  node [shape=box,style=filled,color=lightgray];
  "rev 0" -> "rev 1" -> "rev 2" -> "rev 3";
  "rev 2" -> "rev 4";
  label = "store";
 }
 subgraph cluster_0 {
  style=filled;
  color=lightgrey;
  node [style=filled,color=white];
  edge [style=invis];
  "main.c"->  "main.h" ->  ".hgignore" ->  ".hgtags"
  label="cartella di lavoro";
 }
 "rev 2" -> ".hgtags" [style = dotted lhead = cluster_0 constraint=false]
 "rev 4" -> ".hgtags" [lhead = cluster_0 constraint=false]
 ".hgtags" -> "rev 4" [color = red label = "commit" ltail = cluster_0 constraint=false]
}
}}}

Notare nell'immagine, che la revisione 4 è una '''ramificazione''' della revisione 2, che era la revisione nella cartella di lavoro. Ora la revisione 4 è la revisione "padre" rispetto alla cartella di lavoro.

== Revisioni, Changeset, Head e Tip ==

Mercurial raggruppa i cambiamenti relativi a più file in un singolo '''Changeset''', ossia una lista di tutti i cambiamenti al progetto già presente nel repository.
Dal momento che Mercurial consente lo sviluppo distribuito parallelo, questi numeri di revisione potrebbero essere diversi tra un utente e un altro. Per questo motivo anche Mercurial assegna a ciascuna revisione un numero d'identificazione univoco('''changeset ID'''). Questi ultimi sono codificati con numeri esadecimali a 40 cifre, tuttavia possono essere abbreviati in un qualsiasi prefisso che non sia ambiguo, per esempio "e38487".
{{{#!dot
digraph {
   rankdir = LR
   node [shape=box]
   "rev 0:838e" -> "rev 1:34ef" -> "rev 2:4563"
   "rev 1:34ef" -> "rev 3:fe56"
   "rev 2:4563" -> "rev 4:ac98"
   "rev 3:fe56" -> "rev 4:ac98"
   "rev 4:ac98" -> "rev 5:0345"
   "rev 4:ac98" -> "rev 6:19e3 (tip)"
   label="example history"
}
}}}

Ramificazioni e '''merge'''(ossia quando due revisioni diverse si riuniscono in un repository solo) possono trovarsi in qualsiasi punto della cronologia delle revisioni. Ogni ramificazione che non si riunisce ad un'altra in un merge crea una nuova '''head'''(ossia un changeset senza "figli")nella cronologia delle revisioni. Notare qui come le revisioni 5 e 6 siano head. Inoltre, sempre nell'esempio, Mercurial considera la revisione 6 come '''tip''' del repository, ossia la head col più alto numero di revisioni e dunque la più recente.

== Clone, apportare cambiamenti al codice, Merge e Pull ==

Iniziamo con l'utente Alice, che ha uno '''store''' tipo questo:

{{{#!dot
digraph {
   label="Repository di Alice"
   rankdir = LR
   node [shape=box]
   a->b->c->d
}
}}}

Bob "clona" (comando '''clone''') questo repository e ottiene una copia completa dello store di Alice (nonostante la sua cartella di lavoro sia indipendente!):

{{{#!dot
digraph {
   label="Repository di Bob"
   rankdir = LR
   node [shape=box]
   a->b->c->d
}
}}}

Bob effettua un paio di cambiamenti al codice:

{{{#!dot
digraph {
   label="Repository di Bob"
   rankdir = LR
   node [shape=box]
   a->b->c->d->e->f
   e [color=blue]
   f [color=blue]
}
}}}

Alice intanto fa i suoi cambiamenti in parallelo:

{{{#!dot
digraph {
   label="Repository di Alice"
   rankdir = LR
   node [shape=box]
   a->b->c->d->g
   g [color=red]
}
}}}

Bob allora aggiorna il proprio repository con quello di Alice (comando '''pull''') per sincronizzarlo col suo. Questa operazione copia tutti i cambiamenti di Alice nel repository di Bob:

{{{#!dot
digraph {
   label="Repository di Bob"
   rankdir = LR
   node [shape=box]
   a->b->c->d->e->f
   e [color=blue]
   f [color=blue]
   d->g
   g [color=red;label="g (tip)"]
}
}}}

Considerando che il g di Alice è l'head più recente nel repository di Bob, adesso viene segnato come tip. Bob allora esegue il merge, ossia unifica l'ultimo cambiamento sul quale ha lavorato ('''f''') con il tip, modificando il risultato, e trovandosi con:

{{{#!dot
digraph {
   label="Repository di Bob"
   rankdir = LR
   node [shape=box]
   a->b->c->d->e->f
   e [color=blue]
   f [color=blue]
   d->g
   g [color=red]
   f->h
   g->h
   h [color=green;label="h (tip)"]
}
}}}

Ora se Alice eseguisse l'operazione di pull da Bob, essa otterrebbe i cambiamenti e,f e h effettuati da Bob; inoltre sarebbero completamente sincronizzati:

{{{#!dot
digraph {
   label="Repository di Alice"
   rankdir = LR
   node [shape=box]
   a->b->c->d->g
   d->e->f
   e [color=blue]
   f [color=blue]
   g [color=red]
   f->h
   g->h
   h [color=green;label="h (tip)"]
}
}}}

== Un Sistema Decentralizzato ==

Mercurial è un sistema completamente decentralizzato, ciò significa che non ha il concetto di repository centrale. In questa maniera gli utenti sono liberi di organizzare la propria topologia per condividere le modifiche (cfr. CommunicatingChanges):

{{{#!dot
digraph {
   Alice -> Central
   Central -> Alice
   Bob -> Central
   Alice -> Bob
   Alice -> Carl
   Carl -> Central
   Bob -> Carl
   Carl -> Bob
   "Carl's Laptop" -> Carl
   Carl -> "Carl's Laptop"
   "Carl's Laptop" -> Central
   Central [style=fill;color=blue;label="Main Public Repo"]
   label="A Mercurial Network"
}
}}}

== Cosa Mercurial NON può fare ==

Molti utenti di SVN/CVS si aspettano di conservare in un solo repository progetti collegati. Questo non è il fine per il quale Hg è stato fatto, così che si possa trovare una maniera diversa di lavorare. Questo significa in particolare, che non è possibile controllare una sola cartella di un repository. Ad ogni modo, se proprio si avesse la necessità di conservare più progetti in una specie di meta-repository, suggeriamo di provare a usare la ForestExtension.

Per una pratica introduzione all'utilizzo di Mercurial, fare riferimento al [[Tutorial]].

----
CategoryItalian