Differences between revisions 37 and 38
⇤ ← Revision 37 as of 2013-08-26 14:31:30 →
Size: 487
Editor: Aaron80B
Comment:
← Revision 38 as of 2013-10-08 10:26:58 → ⇥
Size: 2526
Editor: MattiJagula
Comment: Revert spam message
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
Greetings. Allow me begin by [[http://en.wikipedia.org/wiki/Storytelling|telling]] you the author's identify - Matt though it is not his start identify. Delaware is his start place but he demands to go for the reason that of his family members. Because he was eighteen he is been working as a receptionist. One of his beloved hobbies is bungee leaping but he cannot make it his profession. You can constantly find his web-site in this article: http://www.yahad38.co.il/wordpress/?p=725 (for details from a source code point of view, see WhatGoesWhere)

<<TableOfContents>>

== Data structures ==

'''Nodeids''' are unique ids that represent the contents of a file ''and'' its
position in the project history. See [[Nodeid]].

A '''revlog''', for example {{{.hg/data/somefile.d}}}, is the most important
data structure and represents all versions of a file. See [[Revlog]].

A '''manifest''' describes the state of a project by listing each file and
its nodeid to specify which version. See [[Manifest]].

A '''changeset''' lists all files changed in a checkin along with a change
description and metadata like user and date. See [[ChangeSet]].

== Putting it all together ==

We now have enough information to see how this all works together. To look up a given revision of a file:

 * look up the changeset in the changeset index
 * reconstruct the changeset data from the revlog
 * look up the manifest nodeid from the changeset in the manifest index
 * reconstruct the manifest for that revision
 * find the nodeid for the file in that revision
 * look up the revision of that file in the file's index
 * reconstruct the file revision from the revlog

If we want to go the other way and find the changeset associated with a given file revision, we follow the linkrev.

{{{

   .--------linkrev-------------.
   v |
.---------. .--------. .--------.
|changeset| .->|manifest| .->|file |---.
|index | | |index | | |index | |--.
`---------' | `--------' | `--------' | |
    | | | | | `-------' |
    V | V | V `-------'
.---------. | .--------. | .---------.
|changeset|-' |manifest|-' |file |
|data | |data | |revision |
`---------' `--------' `---------'

}}}

== Tracking Working Directory State ==

The other piece of Mercurial is the [[WorkingDirectory|working directory]]. Mercurial tracks various information about the working directory. See DirState.

== Merging ==

See [[Merge]].

== Rollback ==

See [[Rollback]].

== References ==
 * ''"Towards a Better SCM: Revlog and Mercurial"'', Matt Mackall ([[attachment:Presentations/ols-mercurial-paper.pdf|PDF]])
 * ''[[http://hgbook.red-bean.com/hgbookch4.html#x8-640004|"Behind the scenes"]]'' in ''[[http://hgbook.red-bean.com/hgbook.html|"Distributed revision control with Mercurial"]]'', Bryan O’Sullivan

see also: [[Presentations]]
----
CategoryInternals

(for details from a source code point of view, see WhatGoesWhere)

Contents

  1. Data structures
  2. Putting it all together
  3. Tracking Working Directory State
  4. Merging
  5. Rollback
  6. References

Data structures

Nodeids are unique ids that represent the contents of a file and its position in the project history. See Nodeid.

A revlog, for example .hg/data/somefile.d, is the most important data structure and represents all versions of a file. See Revlog.

A manifest describes the state of a project by listing each file and its nodeid to specify which version. See Manifest.

A changeset lists all files changed in a checkin along with a change description and metadata like user and date. See ChangeSet.

Putting it all together

We now have enough information to see how this all works together. To look up a given revision of a file:

  • look up the changeset in the changeset index
  • reconstruct the changeset data from the revlog
  • look up the manifest nodeid from the changeset in the manifest index
  • reconstruct the manifest for that revision
  • find the nodeid for the file in that revision
  • look up the revision of that file in the file's index
  • reconstruct the file revision from the revlog

If we want to go the other way and find the changeset associated with a given file revision, we follow the linkrev. 

   .--------linkrev-------------.
   v                            |
.---------.    .--------.    .--------.
|changeset| .->|manifest| .->|file    |---.
|index    | |  |index   | |  |index   |   |--.
`---------' |  `--------' |  `--------'   |  |
    |       |      |      |     | `-------'  |
    V       |      V      |     V    `-------'
.---------. |  .--------. |  .---------.
|changeset|-'  |manifest|-'  |file     |
|data     |    |data    |    |revision |
`---------'    `--------'    `---------'

Tracking Working Directory State

The other piece of Mercurial is the working directory. Mercurial tracks various information about the working directory. See DirState.

Merging

See Merge.

Rollback

See Rollback.

References

see also: Presentations

CategoryInternals

Design (last edited 2013-10-08 10:26:58 by MattiJagula)