/brz/remove-bazaar

To get this branch, use:
bzr branch http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar

« back to all changes in this revision

Viewing changes to breezy/help_topics/en/glossary.txt

  • Committer: Canonical.com Patch Queue Manager
  • Date: 2010-02-11 04:02:41 UTC
  • mfrom: (5017.2.2 tariff)
  • Revision ID: pqm@pqm.ubuntu.com-20100211040241-w6n021dz0uus341n
(mbp) add import-tariff tests

Show diffs side-by-side

added added

removed removed

Lines of Context:
breezy/help_topics/en/glossary.txt
1
 
Glossary
2
 
========
3
 
 
4
 
.. glossary::
5
 
 
6
 
  ancestor
7
 
    An ancestor is one of any of the revisions that this revision is based on.
8
 
    The immediately prior revision has a special name, the
9
 
    :term:`parent revision`.
10
 
 
11
 
  ancestral parent
12
 
    Any branch that has been merged by another branch and then committed
13
 
    becomes that branches ancestral parent.
14
 
 
15
 
  branch
16
 
    a line of development. In the simplest of terms, a branch is the record of
17
 
    all the commits that have been done. Every :term:`working tree` has a
18
 
    branch, but it may be in a different location. The actual revisions
19
 
    produced by the commits are stored in a repository, which is sometimes
20
 
    shared with other
21
 
    branches.
22
 
 
23
 
    A frequent activity done by users within the working tree of a branch is to
24
 
    merge another branch. In this way users can share changes between two
25
 
    branches -- even if the branch is run by someone else.
26
 
 
27
 
    Bazaar's default behavior is to put the repository, branch, and working
28
 
    tree all in the same place. This combination is called a standalone tree.
29
 
    If there is no tree, it is called a :term:`standalone branch`. If the
30
 
    repository is shared with other branches, it is called a repository branch.
31
 
    A working tree in a different location from its branch is called a
32
 
    checkout.
33
 
 
34
 
  branch, bound
35
 
    A bound branch is a branch that does not commit a new revision until after
36
 
    the revision has been applied to another branch and first.
37
 
 
38
 
    A bound branch is a part of a :term:`heavyweight checkout`.
39
 
 
40
 
  cherry-pick
41
 
    A cherrypick is an operation in which the delta between two revisions is
42
 
    applied to a working tree. The process is roughly similiar to generating a
43
 
    diff between two revisions and applying it to a working tree.
44
 
 
45
 
    A cherrypick is a merge in which a range of revisions are selected and
46
 
    merged into a working tree . Performing a limited merge is different than a
47
 
    normal merge because normal merges imply all missing revisions should be
48
 
    merged. One of the results of cherrypicking is the creation of intransitive
49
 
    ancestors, which are revisons that are missing one or more of their
50
 
    ancestors.
51
 
 
52
 
    A cherrypick in Bazaar is a bit more advanced than the cherrypick with some
53
 
    other revision control systems, in that a three way merge is performed
54
 
    rather than a strict delta between revisions.
55
 
 
56
 
    The downside to cherrypicking is that Bazaar does not track cherrypicked
57
 
    revisions, although this feature is firmly on the wish list.
58
 
 
59
 
    A common use-case for cherrypicking is the back-porting of fixes from an
60
 
    ongoing branch of development to stable release branches.
61
 
 
62
 
  checkout
63
 
    A checkout is essentially a working tree that is linked to a branch at a
64
 
    different location.
65
 
 
66
 
    Checkouts also have local branches, which function as a local cache. This
67
 
    means that checkouts can be used effectively even with branches that are
68
 
    accessed through the Internet. Normal checkouts are sometimes called
69
 
    heavyweight checkouts to distinguish them from lightweight checkouts.
70
 
 
71
 
    A lightweight checkout is a related construct that lacks the local branch.
72
 
    Lightweight checkouts are smaller, but require fast access to the branch,
73
 
    such as on a LAN or local hard disk.
74
 
 
75
 
    Checkouts provide a location for people to hack on code and commit. Once a
76
 
    user commits, the associated branch is updated with a new revision that
77
 
    represents the changes for the commit.
78
 
 
79
 
  dag
80
 
    Directed Acyclic Graph. The graph of revisions where each revision is
81
 
    connected to its parent revisions.
82
 
 
83
 
  delta
84
 
    A delta is defined as the changes between two revisions. Any RCS that has
85
 
    revisions typically builds a delta in order to perform a diff
86
 
 
87
 
  merge
88
 
    Merging is the process of applying all the changes that were introduced in
89
 
    one branch into another branch, without applying any changes that are
90
 
    already common to both branches. Sometimes a user will not want all of the
91
 
    changes. For these cases, a user may instead prefer a cherrypick, which
92
 
    gives the user the option to apply only those revisions that are wanted.
93
 
 
94
 
    As well as altering the working tree, bzr's merge command will also get all
95
 
    of the revisions that a branch has, and add metadata indicating that a
96
 
    merge has been performed.
97
 
 
98
 
  merge, criss-cross
99
 
    A failed type of merge caused by two branches merging each other at the
100
 
    same time.
101
 
 
102
 
  nuclear launch codes
103
 
    Nuclear launch codes are an example of data that has been committed to a
104
 
    branch that must be removed at all costs. Imagine if one had access to the
105
 
    launch codes for a nuclear warhead, accidentally committed them to a branch
106
 
    and then pushed the branch to a public place.
107
 
 
108
 
    In real world situations most people do not have access to nuclear
109
 
    launchcodes. Users may have data such as passwords, proprietary code and
110
 
    other sensitive data. Accidental release of this type of data is
111
 
    potentially damaging to the branch owner -- perhaps damaging enough that
112
 
    the developer may hope for a nuclear disaster!
113
 
 
114
 
    A user dealing with a nuclear launch code problem needs specific data in
115
 
    the branch to be exised at all costs and in a rapid manner.
116
 
 
117
 
  repository
118
 
    A library of revisions for branches.
119
 
 
120
 
  revision
121
 
    A revision is one state of the code.
122
 
 
123
 
    bzr is snapshot based, meaning that conceptually it stores the whole state
124
 
    of the tree at each revision. This is in contrast to changeset based, where
125
 
    a revision refers to just the changes that were made in that revision. I
126
 
    said "conceptually", as internally bzr uses delta compression to reduce the
127
 
    amount of data that it stores, and so may only record the changes in a
128
 
    revision. However you must always think of a revision as referring to a
129
 
    whole snapshot.
130
 
 
131
 
    A revision also contains some metadata. In particular it stores the
132
 
    committer, and the timestamp when the commit was made, the log message that
133
 
    was given, and the nick of the branch on which the commit was made. It also
134
 
    stores pointers to the parent revisions, i.e. the revision preceeding it,
135
 
    and the tip revisions of any branches that were merged. Lastly it stores a
136
 
    number of revision properties, these is extra information that can be
137
 
    stored with the revision and is immutable, some uses of them are to store
138
 
    the author of the patch if it wasn't the committer (when given using the
139
 
    --author option of bzr commit), or to store information about the bugs
140
 
    fixed in that revision if using the bug-tracker integration.
141
 
 
142
 
    A revision also has a name, referred to as a revision id. This is a
143
 
    globally unique identifier for the revision so that it can be referred to
144
 
    without ambiguity. This means that two revisions are identical, if, and
145
 
    only if, they have the same revision id.
146
 
 
147
 
    A revision may also be referred to using a revision number, however this is
148
 
    not a globally unique identifier, meaning that revision 14 of your branch
149
 
    may not be the same as revision 14 of my branch, even if they are the same
150
 
    project. The only way to know if they are the same revision is to compare
151
 
    the revision ids. This means that when talking about a revision you must
152
 
    either use it's revision id, or also explain which branch you are referring
153
 
    to when you specify a revision number.
154
 
 
155
 
    Tags point at a revision, and so they may also be used to when referring to
156
 
    a commit, but again, two different branches may have the same tag name
157
 
    pointing to two different revisions, and so you should also give the branch
158
 
    to which you are referring when stating a tag name.
159
 
 
160
 
  revision, ancestor
161
 
    An ancestor is one of any of the revisions that this revision is based on.
162
 
    The immediately prior revision has a special name, the parent revision.
163
 
 
164
 
  revision, ghost
165
 
    A ghost :term:`revision`, also called a ghost, is a revision that a
166
 
    :term:`branch` knows about but does not have.
167
 
 
168
 
    Ghost revisions can occur in unusual situations such as the migration of
169
 
    branches from foreign revision control systems into Bazaar format.
170
 
 
171
 
    Ghost revisions can be scary the first time that a user bumps into them.
172
 
    Thankfully though, revision ghosts are just like real ghosts (such as they
173
 
    are) in that their discorporeal existence typically causes little, if any,
174
 
    harm.
175
 
 
176
 
  revision, parent
177
 
    The revision that comes immediately prior to this revision.
178
 
 
179
 
  shared repository
180
 
    A shared repository is similar to the traditional concept of a repository
181
 
    in other VCSs like CVS and Subversion. For example, in Subversion you have
182
 
    a remote repository, which is where all of the history is stored, and
183
 
    locally you don't have any history information, only a checkout of the
184
 
    working tree files. Note that "Shared" in this context means shared between
185
 
    branches. It *may* be shared between people, but standalone branches
186
 
    can also be shared between people.
187
 
 
188
 
    In Breezy_ terms, a "Shared Repository" is a location where multiple
189
 
    branches can **share** their revision history information. In order to
190
 
    support decentralized workflows, it is possible for every branch to
191
 
    store its own revision history information. But this is often
192
 
    inefficient, since related branches share history, and they might as
193
 
    well share the storage as well.
194
 
 
195
 
  tag
196
 
    A tag is a nickname for a particular :term:`revision`. The typical use is to mark a
197
 
    release of the software so you can easily refer to it later.
198
 
 
199
 
  working tree
200
 
    A working tree is a directory with project files that a user can edit.
201
 
 
202
 
    Unlike a normal directory, a working tree is associated with a
203
 
    :term:`branch`. The working tree is the space in which commands such as
204
 
    commit and revert operate.