Differences between revisions 2 and 48 (spanning 46 versions)
Revision 2 as of 2010-04-07 16:23:35
Size: 10604
Editor: Tovim
Comment:
Revision 48 as of 2012-04-27 19:21:55
Size: 11235
Editor: Tovim
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
#pragma section-numbers 2
#language cs
## page was renamed from CzechUnderstandingHg
## page was renamed from CzechUnderstandingMercurial
## page was renamed from Základy Mercurialu
= Základní pojmy Mercurialu =
Line 3: Line 9:
See the [[Tutorial]] for step-by-step instructions.

''(Translations:
[[BrazilianPortugueseUnderstandingMercurial|Brazilian Portuguese]],
[[ChineseUnderstandingMercurial|Chinese]],
[[CzechUnderstandingMercurial|Czech]],
[[FrenchUnderstandingMercurial|French]],
[[GermanUnderstandingMercurial|German]],
[[ItalianUnderstandingMercurial|Italian]],
[[JapaneseUnderstandingMercurial|Japanese]],
[[KoreanUnderstandingMercurial|Korean]],
[[RussianUnderstandingMercurial|Russian]],
[[SpanishUnderstandingMercurial|Spanish]],
[[ThaiUnderstandingMercurial|Thai]]
)''

Line 22: Line 11:
== Co je repozitář ==

Termín [[Repository|repozitář]] má dva významy. V užším smyslu to je složka *.hg* v adresáři projektu. V šírším smyslu to je úložný prostor pro zaznamenávání změn. Soubory a složky měněných souborů jsou přítomny či nepřítomny v adresáři projektu, neboli v [[WorkingDirectory|pracovním adresáři]].Obsah pracovního adresáře se mění podle nastavené aktuální revize:
== Repozitář ==

Přísně vzato, [[Repository|repozitář]] je složka '''.hg''', nalézající se v kořenovém adresáři projektu. Další složky a soubory kořenového adresáře vytvářejí tak zvaný '''pracovní prostor''', neboli [[WorkingDirectory|pracovní adresář]].

Repozitář obsahuje historii projektu, pracovní adresář obsahuje časový snímek (snapshot) projektu v určitém bodě historie. Jeho skladba je tedy proměnná.

Často se nepřesně jako repozitář označuje celý kořenový adresář.

== Co je v repozitáři ==
Historie projektu se v repozitáři (složce .git) ukládají ve složce '''store''':
Line 34: Line 30:
  color=lightgrey;je   color=lightgrey;
Line 40: Line 36:
  label = "záznam v repozitáři";   label = "složka .git/store";
Line 51: Line 47:
Repozitář obsahuje '''úplnou''' historii projektu. Na rozdíl od tradičních [[SCM|SCM]], kde existuje pouze jedna centrální kopie této historie, má každý pracovní adresář v Mercurialu svou vlastní kopii. To umožňuje paralelní vývoj projektů.

Pracovní adresář tedy obsahuje editovatelné kopie souborů, odpovídající zadané aktuální revizi - včetně souborů [[.hgignore|ignorovaných]].

== Committing Changes ==

When you [[Commit|commit]], the state of the working directory relative to its [[Parent|parents]] is recorded as a new [[ChangeSet|changeset]] (also called a new "[[Revision|revision]]"):
Na rozdíl od tradičních [[SCM|SCM]], kde existuje pouze jedna centrální kopie historie, je každý pracovní adresář spojen se svou vlastní kopii historie. To umožňuje paralelní vývoj projektů.

Pracovní adresář obsahuje kopii projektových souborů v učitém časovém bodě (např. rev. 2) připravených k editování. Protože [[Tag|tagy]] a [[.hgignore|ignorované soubory]] jsou také verzovány, jsou rovněž (pokud existují) součástí pracovního adresáře.

== Potvrzení změn ==
Provedením příkazu [[Commit|commit]] se stav pracovního adresáře vztažený ke svým [[Parent|rodičům]] zapíše jako nový [[ChangeSet|changeset]], nesprávně označovaný také jako [[Revision|revize]].

Přísně vzato, '''revize''' značí změnu souboru či složky. Jeden '''changeset''' (sada změn) může mít více revizí. Vhodnějším ekvivalentem pro slovo "changeset" by mohlo být slovo '''verze'''. Následující ilustrace ale používá termín "revize".
Line 65: Line 62:
  label="working directory";   label="pracovní adresář";
Line 81: Line 78:
 "rev 2" -> ".hgtags" [dir=back, style=dotted, lhead=cluster_0, label="parent before commit"]  "rev 2" -> ".hgtags" [dir=back, style=dotted, lhead=cluster_0, label="rodič rev. 3 a 4"]
Line 86: Line 83:
Note here that revision 4 is a '''[[Branch|branch]]''' of revision 2, which was the revision in the working directory. Now revision 4 is the working directory's '''parent'''.

== Revisions, Changesets, Heads, and Tip ==

Mercurial groups related changes to multiple files into single atomic [[ChangeSet|changesets]], which are revisions of the whole project.
These each get a sequential [[RevisionNumber|revision number]]. Because Mercurial allows distributed parallel development, these revision numbers may disagree between users. So Mercurial also assigns each revision a global [[ChangeSetID|changeset ID]]. Changeset IDs are 40-digit hexadecimal numbers, but they can be abbreviated to any unambiguous prefix, like "e38487".
Revize 4 byla vytvořena v situaci, kdy již existovala revize 3 a aktuální revizí pracovního adresáře byla revize 2. Revize 4 tvoří novou '''[[Branch|větev]]''' v historii changesetů.

== Revize, changesety, čela a tip ==
Mercurial sdružuje změny ve vícerých souborech do jednotlivých atomických (nedělitelných)
[[ChangeSet|changesetů]], které jsou revizemi (verzemi) celého projektu.
Každému changesetu je přiřazeno pořadové [[RevisionNumber|číslo revize]]. Protože Mercurial umožňuje decentralizovaný paralelní vývoj projektů, bývají tato čísla u různých uživatelů různá.
Z tohoto důvodu uděluje Mercurial každé revizi také globální [[ChangeSetID|ID changesetu]]. Jsou to čtyřicetimístná hexadecimální čísla, jež mohou být zkrácena na libovolně krátký počet znaků, pokud mají jednoznačný význam, jako např. "e38487".
Line 104: Line 102:
   workingdir [label="{{<p1> p1 | <p2> p2} | working directory}"];    workingdir [label="{{<p1> p1 | <p2> p2} | pracovní adresář}"];
Line 113: Line 111:
   label="example repository"
}
}}}

Branches and [[Merge|merges]] in the revision history can occur at any point. Each unmerged branch creates a new [[Head|head]] of the revision history.
Here, revisions 5 and 6 are heads. Mercurial considers revision 6 to be the [[Tip|tip]] of the repository, the head with the highest revision number.
Revision 4 is a [[MergeChangeset|merge changeset]], as it has ''two'' parent changesets (revisions 2 and 3).

== Cloning, Making Changes, Merging, Pulling and Updating ==

Let's start with a user Alice, who has a repository that looks like:

{{{#!dot
digraph {
   label="Alice's repo"
   label="příklad záznamu v repozitáři"
}
}}}

Větvení a [[Merge|slučování]] se může vyskytnout kdekoliv v historii projektu. Každá nesloučená větev vytváří nové [[Head|čelo]] (head) historie. V naší ukázce jsou čely revize 5 a 6. Revize 6 je považována za [[Tip|tip]] repozitáře, čelo s nejvyšším číslem revize. Revize 4 je [[MergeChangeset|slučovací changeset]], protože má dva rodičovské changesety (revize 2 a 3).

== Klonování, slučování, akce pull a update ==
Začněme s Alenkou, jejíž repozitář vypadá následovně:

{{{#!dot
digraph {
   label="Alenčin repozitář"
Line 134: Line 129:
Bob [[Clone|clones]] this repo, and ends up with a complete, independent, local copy of Alice's store
and a clean checkout of the tipmost revision d in his working directory:

{{{#!dot
digraph {
   label="Bob's repo"
Pracovní adresář (working directory) je opět uváděn jako poslední (potenciální) changeset.

Bertík si vytvoří [[Clone|klon]] tohoto repozitáře a tím získá úplnou, nezávislou lokální kopii Alenčiny složky 'store' ve svém vlastním adresáři:

{{{#!dot
digraph {
   label="Bertíkův repozitář"
Line 146: Line 142:
Bob can now work independently of Alice. He then [[Commit|commits]] two changes e and f:

{{{#!dot
digraph {
   label="Bob's repo"
Bertík nyní může pracovat nezávisle na Alence. Vytvoří dvě změny '''e''','''f''', které potvrdí příkazem [[Commit|commit]]:

{{{#!dot
digraph {
   label="Bertíkův repozitář"
Line 159: Line 155:
Alice then makes her own change g in parallel, which causes her repository store to diverge from Bob's, thus
creating a [[Branch|branch]]:

{{{#!dot
digraph {
   label="Alice's repo"
Alenka si vytvoří svou vlastní paralelní změnu '''g''':

{{{#!dot
digraph {
   label="Alenčin repozitář"
Line 172: Line 167:
Bob then [[Pull|pulls]] Alice's repo to synchronize. This copies all of Alice's changes into Bob's repository store
(here, it's just a single change g). Note that Bob's working directory is '''not''' changed
by the pull:

{{{#!dot
digraph {
   label="Bob's repo"
Nyní se Bertík synchronizuje s Alenkou pomocí příkazu [[Pull|pull]]. Tímto příkazem zkopíruje všechny změny Alenčina repozitáře (zde pouze změnu g) do svého repozitáře.


{{{#!dot
digraph {
   label="Bertíkův repozitář"
Line 189: Line 183:
Because Alice's '''g''' is the newest head in Bob's repository, it's now the '''tip'''.

Bob then does a [[Merge|merge]], which combines the last change he was working on (f) with the
tip in his repository. Now, his working directory has two parent revisions (f and g):

{{{#!dot
digraph {
   label="Bob's repo"
Protože nejnovějším čelem v Bertíkově repozitáři je Alenčin changeset '''g''', je nositelem označení ''tip''.


Bertík dále provede příkaz [[Merge|merge]] (sloučení), který spojí jeho poslední revizi (f) s posledním changesetem (tipem) jeho repozitáře (g). Jeho pracovní adresář má nyní dvě rodičovské revize (f, g):

{{{#!dot
digraph {
   label="Bertíkův repozitář"
Line 209: Line 203:
After examining the result of the merge in his working directory and making sure the merge is
perfect, Bob commits the result and ends up with a new [[MergeChangeset|merge changeset]] h in his
store:

{{{#!dot
digraph {
   label="Bob's repo"
Po kontrole pracovního adresáře, že sloučení je v pořádku, vytvoří Bertík příkazem commit [[MergeChangeset|slučující changeset]] '''h''' ve svém repozitáři:

{{{#!dot
digraph {
   label="Bertíkův repozitář"
Line 230: Line 222:
Now if Alice '''pulls''' from Bob, she will get Bob's changes e, f, and h into her store:

{{{#!dot
digraph {
   label="Alice's repo"
Když si nyní Alenka přetáhne (příkazem [[Pull|pull]]) změny od Bertíka, přejdou do jejího repozitáře revize '''e''','''f''' a '''h''':

{{{#!dot
digraph {
   label="Alenčin repozitář"
Line 249: Line 241:
Note that Alice's working directory was not changed by the pull. She has to do an [[Update|update]] to synchronize
her working directory to the merge changset h. This changes the parent changeset of her working directory to
changeset h and updates the files in her working directory to revision h.

{{{#!dot
digraph {
   label="Alice's repo"
Všimneme si, že provedením příkazu pull se Alenčin pracovní adresář rovněž nezměnil. Ta musí ještě provést příkaz [[Update|update]] aby synchronizovala svůj pracovní adresář se slučujícím changesetem '''h'''. Ten se stane rodičovským changesetem jejího pracovního adresáře.

{{{#!dot
digraph {
   label="Alenčin repozitář"
Line 270: Line 260:
Now Alice and Bob are fully synchronized again.


== A Decentralized System ==

Mercurial is a completely decentralized system, and thus has no internal notion of a central repository. Thus users are free to define their own topologies for sharing changes (see 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"
}
}}}

Unlike a centralized version control system in which experimentation
can be disastrous, with a DVCS like Mercurial, you just clone and
experiment. If you like the results, push them back, otherwise
wipe the cloned repository and try something else.


== What Mercurial can't do ==

Many SVN/CVS users expect to host related projects together in one repository. This is really not what Mercurial was made for, so you should try a different way of working. In particular, this means that you cannot check out only one directory of a repository.

If you absolutely need to host multiple projects in a kind of meta-repository though, you could try the [[subrepos|Subrepositories]] feature that was introduced with Mercurial 1.3 or the older ForestExtension.


For a hands-on introduction to using Mercurial, see the [[Tutorial]].
Nyní jsou Alenčin a Bertíkův repozitář plně synchronizovány.


== Decentralizovaný systém ==
Mercurial je úplně decentralizovaný systém bez cenrálního repozitáře. Uživatelé si mohou volně definovat své konstelace pro sdílení změn (viz CommunicatingChanges), včetně vyčlenění jednoho repozitáře jako centrálního:

{{{#!dot
digraph {
   Alenka -> Centrum
   Centrum -> Alenka
   Bertík -> Centrum
   Alenka -> Bertík
   Alenka -> Karel
   Karel -> Centrum
   Bertík -> Karel
   Karel -> Bertík
   "Karlův laptop" -> Karel
   Karel -> "Karlův laptop"
   "Karlův laptop" -> Centrum
   Centrum [style=fill;color=blue;label="Main Public Repo"]
   label="Síť Mercurialu"
}
}}}

Na rozdíl od centralizovaných systémů správy verzí, u nichž experimentování může končit pohromou, u systémů DVCS, jako je Mercurial si prostě vytvoříme klon a experimentujeme. Pokud jsme s výsledkem spokojeni, předáme jej dál, pokud ne, můžeme klonovaný repozitář smazat a zkusit něco jiného.


== Co Mercurial neumí ==
Mnozí uživatelé SVN/CVS mohou mylně očekávat, že lze v jednom repozitáři sledovat více projektů. Pro toto použití není Mercurial stavěn.

Pokud je nezbytně nutné hostovat více projektů v jednom místě, je možné zkusit nástroj [[subrepos|Subrepositář]], který byl zaveden v Mercurialu 1.3 nebo starší ForestExtension.


##Podrobnější text o používání Mercurialu viz [[CzechTutorial|Tutoriál pro Mercurial]].
Line 310: Line 295:
CategoryCzech CategoryCzech

Základní pojmy Mercurialu

Decentralizovaný model Mercurialu může být pro nového uživatele matoucí. Tato stránka se pokouší osvětlit některé z jeho základních pojmů.

1. Repozitář

Přísně vzato, repozitář je složka .hg, nalézající se v kořenovém adresáři projektu. Další složky a soubory kořenového adresáře vytvářejí tak zvaný pracovní prostor, neboli pracovní adresář.

Repozitář obsahuje historii projektu, pracovní adresář obsahuje časový snímek (snapshot) projektu v určitém bodě historie. Jeho skladba je tedy proměnná.

Často se nepřesně jako repozitář označuje celý kořenový adresář.

2. Co je v repozitáři

Historie projektu se v repozitáři (složce .git) ukládají ve složce store:

Na rozdíl od tradičních SCM, kde existuje pouze jedna centrální kopie historie, je každý pracovní adresář spojen se svou vlastní kopii historie. To umožňuje paralelní vývoj projektů.

Pracovní adresář obsahuje kopii projektových souborů v učitém časovém bodě (např. rev. 2) připravených k editování. Protože tagy a ignorované soubory jsou také verzovány, jsou rovněž (pokud existují) součástí pracovního adresáře.

3. Potvrzení změn

Provedením příkazu commit se stav pracovního adresáře vztažený ke svým rodičům zapíše jako nový changeset, nesprávně označovaný také jako revize.

Přísně vzato, revize značí změnu souboru či složky. Jeden changeset (sada změn) může mít více revizí. Vhodnějším ekvivalentem pro slovo "changeset" by mohlo být slovo verze. Následující ilustrace ale používá termín "revize".

Revize 4 byla vytvořena v situaci, kdy již existovala revize 3 a aktuální revizí pracovního adresáře byla revize 2. Revize 4 tvoří novou větev v historii changesetů.

4. Revize, changesety, čela a tip

Mercurial sdružuje změny ve vícerých souborech do jednotlivých atomických (nedělitelných) changesetů, které jsou revizemi (verzemi) celého projektu. Každému changesetu je přiřazeno pořadové číslo revize. Protože Mercurial umožňuje decentralizovaný paralelní vývoj projektů, bývají tato čísla u různých uživatelů různá. Z tohoto důvodu uděluje Mercurial každé revizi také globální ID changesetu. Jsou to čtyřicetimístná hexadecimální čísla, jež mohou být zkrácena na libovolně krátký počet znaků, pokud mají jednoznačný význam, jako např. "e38487".

Větvení a slučování se může vyskytnout kdekoliv v historii projektu. Každá nesloučená větev vytváří nové čelo (head) historie. V naší ukázce jsou čely revize 5 a 6. Revize 6 je považována za tip repozitáře, čelo s nejvyšším číslem revize. Revize 4 je slučovací changeset, protože má dva rodičovské changesety (revize 2 a 3).

5. Klonování, slučování, akce pull a update

Začněme s Alenkou, jejíž repozitář vypadá následovně:

Pracovní adresář (working directory) je opět uváděn jako poslední (potenciální) changeset.

Bertík si vytvoří klon tohoto repozitáře a tím získá úplnou, nezávislou lokální kopii Alenčiny složky 'store' ve svém vlastním adresáři:

Bertík nyní může pracovat nezávisle na Alence. Vytvoří dvě změny e,f, které potvrdí příkazem commit:

Alenka si vytvoří svou vlastní paralelní změnu g:

Nyní se Bertík synchronizuje s Alenkou pomocí příkazu pull. Tímto příkazem zkopíruje všechny změny Alenčina repozitáře (zde pouze změnu g) do svého repozitáře.

Protože nejnovějším čelem v Bertíkově repozitáři je Alenčin changeset g, je nositelem označení tip.

Bertík dále provede příkaz merge (sloučení), který spojí jeho poslední revizi (f) s posledním changesetem (tipem) jeho repozitáře (g). Jeho pracovní adresář má nyní dvě rodičovské revize (f, g):

Po kontrole pracovního adresáře, že sloučení je v pořádku, vytvoří Bertík příkazem commit slučující changeset h ve svém repozitáři:

Když si nyní Alenka přetáhne (příkazem pull) změny od Bertíka, přejdou do jejího repozitáře revize e,f a h:

Všimneme si, že provedením příkazu pull se Alenčin pracovní adresář rovněž nezměnil. Ta musí ještě provést příkaz update aby synchronizovala svůj pracovní adresář se slučujícím changesetem h. Ten se stane rodičovským changesetem jejího pracovního adresáře.

Nyní jsou Alenčin a Bertíkův repozitář plně synchronizovány.

6. Decentralizovaný systém

Mercurial je úplně decentralizovaný systém bez cenrálního repozitáře. Uživatelé si mohou volně definovat své konstelace pro sdílení změn (viz CommunicatingChanges), včetně vyčlenění jednoho repozitáře jako centrálního:

Na rozdíl od centralizovaných systémů správy verzí, u nichž experimentování může končit pohromou, u systémů DVCS, jako je Mercurial si prostě vytvoříme klon a experimentujeme. Pokud jsme s výsledkem spokojeni, předáme jej dál, pokud ne, můžeme klonovaný repozitář smazat a zkusit něco jiného.

7. Co Mercurial neumí

Mnozí uživatelé SVN/CVS mohou mylně očekávat, že lze v jednom repozitáři sledovat více projektů. Pro toto použití není Mercurial stavěn.

Pokud je nezbytně nutné hostovat více projektů v jednom místě, je možné zkusit nástroj Subrepositář, který byl zaveden v Mercurialu 1.3 nebo starší ForestExtension.


CzechUnderstandingMercurial (last edited 2018-08-03 18:27:01 by Tovim)