/brz/remove-bazaar

To get this branch, use:
bzr branch http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar
2977.1.1 by Ian Clatworthy
First cut at new look User Guide including chapters 1 and 2
1
Core concepts
2
=============
3
4
A simple user model
5
-------------------
6
3074.1.1 by Ian Clatworthy
feedback from mrevell
7
To use Bazaar you need to understand four core concepts:
8
3299.3.3 by Gary Wilson Jr.
Capitalized first word in list items.
9
* **Revision** - a snapshot of the files you're working with.
3299.3.2 by Gary Wilson Jr.
Several small changes to core_concepts docs:
10
3299.3.3 by Gary Wilson Jr.
Capitalized first word in list items.
11
* **Working tree** - the directory containing your version-controlled
3299.3.2 by Gary Wilson Jr.
Several small changes to core_concepts docs:
12
  files and sub-directories.
13
3299.3.3 by Gary Wilson Jr.
Capitalized first word in list items.
14
* **Branch** - an ordered set of revisions that describe the history of a
3299.3.2 by Gary Wilson Jr.
Several small changes to core_concepts docs:
15
  set of files.
16
3299.3.3 by Gary Wilson Jr.
Capitalized first word in list items.
17
* **Repository** - a store of revisions.
3074.1.1 by Ian Clatworthy
feedback from mrevell
18
19
Let's look at each in more detail.
2977.1.1 by Ian Clatworthy
First cut at new look User Guide including chapters 1 and 2
20
21
Revision
22
--------
23
3299.3.2 by Gary Wilson Jr.
Several small changes to core_concepts docs:
24
A revision is a *snapshot* of the state of a tree of files and directories,
2977.1.1 by Ian Clatworthy
First cut at new look User Guide including chapters 1 and 2
25
including their content and shape. A revision also has some metadata
3299.3.2 by Gary Wilson Jr.
Several small changes to core_concepts docs:
26
associated with it, including:
27
3299.3.6 by Gary Wilson Jr.
Removed ending punctuation from simple list.
28
* Who committed it
29
* When it was committed
30
* A commit message
31
* Parent revisions from which it was derived
3299.3.2 by Gary Wilson Jr.
Several small changes to core_concepts docs:
32
33
Revisions are immutable and can be globally, uniquely identified
2977.1.17 by Ian Clatworthy
more chapter 1 tweaks
34
by a *revision-id*. An example revision-id is::
35
36
 pqm@pqm.ubuntu.com-20071129184101-u9506rihe4zbzyyz
3299.3.5 by Gary Wilson Jr.
Removed trailing whitespace.
37
3412.1.3 by Ian Clatworthy
improve rev number explanation using Robert's text
38
Revision-ids are generated at commit time or, for imports from other
39
systems, at the time of import. While revision-ids are necessary
40
for internal use and external tool integration, branch-specific
41
*revision numbers* are the preferred interface for humans.
42
43
Revision numbers are dotted decimal identifiers like 1, 42 and 2977.1.59
44
that trace a path through the revision number graph for a branch.
45
Revision numbers are generally shorter than revision-ids and,
46
within a single branch, can be compared with each other to get a sense
47
of their relationship. For example, revision 10 is the mainline (see below)
48
revision immediately after revision 9. Revision numbers
49
are generated on the fly when commands are executing, because they
50
depend on which revision is the tip (i.e. most recent revision)
51
in the branch.
52
3104.2.4 by Ian Clatworthy
make it clear the Reference has the details of revision spec formats
53
See `Specifying revisions`_ in the appendices for a closer look at
54
the numerous ways that revisions and ranges of revisions can be specified
3299.3.2 by Gary Wilson Jr.
Several small changes to core_concepts docs:
55
in Bazaar, and `Understanding Revision Numbers`_ for a more detailed
56
description of revision numbering.
2977.1.1 by Ian Clatworthy
First cut at new look User Guide including chapters 1 and 2
57
2977.1.9 by Ian Clatworthy
first cut at Distributed collaboration chapter
58
.. *TODO: add diagram*
2977.1.1 by Ian Clatworthy
First cut at new look User Guide including chapters 1 and 2
59
60
Working Tree
61
------------
62
3299.3.2 by Gary Wilson Jr.
Several small changes to core_concepts docs:
63
A working tree is a *version-controlled directory* holding files the user
2977.1.1 by Ian Clatworthy
First cut at new look User Guide including chapters 1 and 2
64
can edit. A working tree is associated with a *branch*.
65
66
Many commands use the working tree as their context, e.g. ``commit`` makes
67
a new revision using the current content of files in the working tree.
68
2977.1.9 by Ian Clatworthy
first cut at Distributed collaboration chapter
69
.. *TODO: add diagram*
2977.1.1 by Ian Clatworthy
First cut at new look User Guide including chapters 1 and 2
70
71
Branch
72
------
73
74
In the simplest case, a branch is an *ordered series of revisions*.
3412.1.3 by Ian Clatworthy
improve rev number explanation using Robert's text
75
The last revision is known as the *tip*.
2977.1.1 by Ian Clatworthy
First cut at new look User Guide including chapters 1 and 2
76
3299.3.2 by Gary Wilson Jr.
Several small changes to core_concepts docs:
77
Branches may split apart and be *merged* back together, forming a
3074.1.1 by Ian Clatworthy
feedback from mrevell
78
*graph* of revisions. Technically, the graph shows directed relationships
79
(between parent and child revisions) and there are no loops, so
80
you may hear some people refer to it as a *directed acyclic graph* or DAG.
81
3299.3.2 by Gary Wilson Jr.
Several small changes to core_concepts docs:
82
If this name sounds scary, don't worry. The important things
83
to remember are:
84
85
* The primary line of development within the DAG is called
3299.3.7 by Gary Wilson Jr.
Added a comma and capitalized first word of a couple list items.
86
  the *mainline*, *trunk*, or simply the *left hand side* (LHS).
3299.3.2 by Gary Wilson Jr.
Several small changes to core_concepts docs:
87
88
* A branch might have other lines of development and if it does,
3074.1.1 by Ian Clatworthy
feedback from mrevell
89
  these other lines of development begin at some point and end at
90
  another point.
91
2977.1.9 by Ian Clatworthy
first cut at Distributed collaboration chapter
92
.. *TODO: add diagram*
2977.1.1 by Ian Clatworthy
First cut at new look User Guide including chapters 1 and 2
93
94
Repository
95
----------
96
3299.3.2 by Gary Wilson Jr.
Several small changes to core_concepts docs:
97
A repository is simply a *store of revisions*. In the simplest case,
2977.1.1 by Ian Clatworthy
First cut at new look User Guide including chapters 1 and 2
98
each branch has its own repository. In other cases, it makes sense for
99
branches to share a repository in order to optimize disk usage.
100
2977.1.9 by Ian Clatworthy
first cut at Distributed collaboration chapter
101
.. *TODO: add diagram*
2977.1.1 by Ian Clatworthy
First cut at new look User Guide including chapters 1 and 2
102
103
Putting the concepts together
104
-----------------------------
105
3299.3.2 by Gary Wilson Jr.
Several small changes to core_concepts docs:
106
Once you have grasped the concepts above, the various ways of using Bazaar
107
should become easier to understand. The simplest way of using Bazaar is
108
to use a *standalone tree*, which has a working tree, branch, and repository
2977.1.1 by Ian Clatworthy
First cut at new look User Guide including chapters 1 and 2
109
all in a single location. Other common scenarios include:
110
3779.2.1 by mernst at mit
Improved documentation of stacked and lightweight branches
111
* `Shared repositories <#a-reminder-about-shared-repositories>`_ - working
112
  tree and branch are colocated, but the repository is in a higher level
113
  directory.
114
115
* `Stacked branches <#using-stacked-branches>`_ - branch stores just its
116
  unique revisions, using its parent's repository for common revisions.
117
118
* `Lightweight checkouts <#getting-a-lightweight-checkout>`_ - branch is 
119
  stored in a different location to the working tree.
3299.3.2 by Gary Wilson Jr.
Several small changes to core_concepts docs:
120
121
The best way to use Bazaar, however, depends on your needs. Let's take a
122
look at some common workflows next.