/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: Jelmer Vernooij
  • Date: 2019-06-15 13:39:46 UTC
  • mto: This revision was merged to the branch mainline in revision 7342.
  • Revision ID: jelmer@jelmer.uk-20190615133946-uywh9ix0lfpqw0hy
Install quilt.

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.