~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to tutorial.txt

[merge] fix \t in commit messages

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
.. This file is in Python ReStructuredText format - it can be formatted
2
 
.. into HTML or text.  In the future we plan to extract the example commands
3
 
.. and automatically test them.
4
 
 
5
 
.. This text was previously on the wiki at 
6
 
.. http://bazaar.canonical.com/IntroductionToBzr
7
 
.. but has been moved into the source tree so it can be kept in sync with
8
 
.. the source and possibly automatically checked.
9
 
 
10
 
===============
11
 
Bazaar Tutorial
12
 
===============
13
 
 
14
 
Current for bzr-0.91, 2007-08
 
1
==================
 
2
Bazaar-NG Tutorial
 
3
==================
 
4
 
 
5
current for bzr 0.0.6pre, July 2005
 
6
 
 
7
 
 
8
*NOTE* For a more current and user-editable version of this 
 
9
document, see the wiki at http://bazaar.canonical.com/IntroductionToBzr
15
10
 
16
11
 
17
12
Introduction
18
13
============
19
14
 
20
 
If you are already familiar with decentralized revision control, then
21
 
please feel free to skip ahead to "Introducing Yourself to Bazaar". If,
22
 
on the other hand, you are familiar with revision control but not
23
 
decentralized revision control, then please start at "How DRCS is
24
 
different." Otherwise, get some coffee or tea, get comfortable and get
25
 
ready to catch up. 
26
 
 
27
 
The Purposes of Revision Control
28
 
================================
29
 
 
30
 
Odds are that you have worked on some sort of textual data -- the sources
31
 
to a program, web sites or the config files that Unix system
32
 
administrators have to deal with in /etc. The chances are also good that
33
 
you have made some sort of mistake that you deeply regretted. Perhaps you
34
 
deleted the configuration file for your mailserver or perhaps mauled the
35
 
source code for a pet project. Whatever happened, you have just deleted
36
 
important information that you would desperately like to get back. If this
37
 
has ever happened to you, then you are probably ready for Bazaar.
38
 
 
39
 
Revision control systems (which I'll henceforth call RCS) such as
40
 
Bazaar give you the ability to track changes for a directory by turning
41
 
it into something slightly more complicated than a directory that we call
42
 
a **branch**. The branch not only stores how the directory looks right
43
 
now, but also how it looked at various points in the past. Then, when you
44
 
do something you wish you hadn't, you can restore the directory to the way
45
 
it looked at some point in the past.
46
 
 
47
 
Revision control systems give users the ability to save changes to a
48
 
branch by "committing a **revision**". The revision created is essentially
49
 
a summary of the changes that were made since the last time the tree was
50
 
saved. 
51
 
 
52
 
These revisions have other uses as well. For example, one can comment
53
 
revisions to record what the recent set of changes meant by providing an
54
 
optional log message. Real life log messages include things like "Fixed
55
 
the web template to close the table" and "Added sftp suppport. Fixes #595"
56
 
        
57
 
We keep these logs so that if later there is some sort of problem with
58
 
sftp, we can figure out when the problem probably happened. 
59
 
 
60
 
How DRCS is Different
61
 
---------------------
62
 
 
63
 
Many Revision Control Systems (RCS) are stored on servers. If one wants to
64
 
work on the code stored within an RCS, then one needs to connect to the
65
 
server and "checkout" the code. Doing so gives one a directory in which a
66
 
person can make changes and then commit. The RCS client then connects to
67
 
the RCS server and stores the changes. This method is known as the
68
 
centralized model. 
69
 
 
70
 
The centralized model can have some drawbacks. A centralized RCS requires
71
 
that one is able to connect to the server whenever one wants to do version
72
 
control work. This can be a bit of a problem if your server is on some other
73
 
machine on the internet and you are not. Or, worse yet, you **are** on the
74
 
internet but the server is missing!
75
 
 
76
 
Decentralized Revision Control Systems (which I'll call DRCS after this
77
 
point) deal with this problem by keeping branches on the same machine as
78
 
the client. In Bazaar's case, the branch is kept in the same place as
79
 
the code that is being version controlled. This allows the user to save
80
 
his changes (**commit**) whenever he wants -- even if he is offline. The
81
 
user only needs internet access when he wants to access the changes in
82
 
someone else's branch that are somewhere else.
83
 
 
84
 
 
85
 
A common requirement that many people have is the need to keep track of
86
 
the changes for a directory such as file and subdirectory changes.
87
 
Performing this tracking by hand is a awkward process that over time
88
 
becomes unwieldy. That is, until one considers version control tools such
89
 
as Bazaar. These tools automate the process of storing data by creating
90
 
a **revision** of the directory tree whenever the user asks. 
91
 
 
92
 
Revision control software such as Bazaar can do much more than just
93
 
storage and performing undo.  For example, with Bazaar a developer can
94
 
take the modifications in one branch of software and apply them to a
95
 
related branch -- even if those changes exist in a branch owned by
96
 
somebody else. This allows developers to cooperate without giving
97
 
write access to the repository.
98
 
 
99
 
Bazaar remembers the ''ancestry'' of a revision: the previous revisions
100
 
that it is based upon.  A single revision may have more than one direct
101
 
descendant, each with different changes, representing a divergence in the
102
 
evolution of the tree. By branching, Bazaar allows multiple people to
103
 
cooperate on the evolution of a project, without all needing to work in
104
 
strict lock-step.  Branching can be useful even for a single developer.
105
 
 
106
 
Introducing yourself to Bazaar
107
 
==============================
108
 
 
109
 
Bazaar installs a single new command, **bzr**.  Everything else is a
110
 
subcommand of this.  You can get some help with ``bzr help``. Some arguments 
111
 
are grouped in topics: ``bzr help topics`` to see which topics are available.
112
 
 
113
 
One function of a version control system is to keep track of who changed
114
 
what.  In a decentralized system, that requires an identifier for each
115
 
author that is globally unique.  Most people already have one of these: an
116
 
email address. Bazaar is smart enough to automatically generate an email
117
 
address by looking up your username and hostname. If you don't like the
118
 
guess that Bazaar makes, then three options exist:
119
 
 
120
 
 1. Set an email address via ``bzr whoami``.  This is the simplest way.
121
 
 
122
 
    To set a global identity, use::
123
 
 
124
 
    % bzr whoami "Your Name <email@example.com>"
125
 
 
126
 
    If you'd like to use a different address for a specific branch, enter
127
 
    the branch folder and use::
128
 
 
129
 
    % bzr whoami --branch "Your Name <email@example.com>"
130
 
 
131
 
 #. Setting the email address in the ``~/.bazaar/bazaar.conf`` [1]_ by
132
 
    adding the following lines.  Please note that  ``[DEFAULT]`` is case
133
 
    sensitive::
134
 
 
135
 
        [DEFAULT]
136
 
        email=Your Name <email@isp.com>
137
 
 
138
 
    As above, you can override this settings on a branch by branch basis
139
 
    by creating a branch section in ``~/.bazaar/locations.conf`` and
140
 
    adding the following lines::
141
 
 
142
 
        [/the/path/to/the/branch]
143
 
        email=Your Name <email@isp.com>
144
 
 
145
 
 
146
 
 #. Overriding the two previous options by setting the global environment
147
 
    variable ``$BZR_EMAIL`` or ``$EMAIL`` (``$BZR_EMAIL`` will take
148
 
    precedence) to your full email address.
149
 
 
150
 
.. [1] On Windows, the users configuration files can be found in the
151
 
   application data directory. So instead of ``~/.bazaar/branch.conf``
152
 
   the configuration file can be found as: 
153
 
   ``C:\Documents and Settings\<username>\Application Data\Bazaar\2.0\branch.conf``.
154
 
   The same is true for ``locations.conf``, ``ignore``, and the
155
 
   ``plugins`` directory.
 
15
Bazaar-NG is a version control tool.  It manages trees of files and subdirectories.  In particular, it records *revisions* of trees, representing their state at a particular point in time, and information about those revisions and their relationships.  Recording and retrieving tree revisions is useful in several ways if you are writing software or documents or doing similar creative work.
 
16
 
 
17
 * Keeping previous revisions lets you go back if you make a mistake or want to check your work.  It acts as a high-level unlimited undo.
 
18
 
 
19
 * By recording comments on every revision, you produce an annotated history of the project, describing what, who, why, and when.
 
20
 
 
21
 * Using a version control tool can be an aid to thinking about a project: getting to a stable state at regular intervals and then writing a description of what you did is an easy way to stay organized and on track.
 
22
 
 
23
Bazaar-NG remembers the *ancestry* of a revision: the previous revisions that it is based upon.  A single revision may have more than one direct descendant, each with different changes, representing a divergence in the evolution of the tree.  
 
24
By branching, Bazaar-NG allows multiple people to cooperate on the evolution of a project, without all needing to work in strict
 
25
lock-step.  Branching can be useful even for a single developer.
 
26
 
 
27
Bazaar-NG installs a single new command,
 
28
*bzr*.  Everything else is a subcommand of this.  You can get
 
29
some help with ``bzr help``.  There will be more in the future.
 
30
 
 
31
 
 
32
 
 
33
Introducing yourself to bzr
 
34
===========================
 
35
 
 
36
One function of a version control system is to keep track of who
 
37
changed what.  In a distributed system that requires an identifier for
 
38
each author that is globally unique.  Most people already have one of
 
39
these: an email address.
 
40
 
 
41
[after 0.0.4] To tell bzr which email address to use, put it in the file
 
42
``$HOME/.bzr.conf/email``, or the environment variable ``$BZREMAIL``.
 
43
If neither of these are set, bzr will use the ``$EMAIL``
 
44
variable, or use your username and hostname.
 
45
 
 
46
To check this has taken effect, or if you forget your own name, use
 
47
the ``whoami`` ("who am i?") command::
 
48
 
 
49
  % bzr whoami
 
50
 
 
51
Some people want to avoid sharing their email address so as not to
 
52
get spam.  bzr will never
 
53
disclose your email address unless you tell it to by publishing an
 
54
archive or transmitting a changeset.  It's recommended that you do use
 
55
a real address, so that people can contact you about your work, but
 
56
it's not required.  You can use an address which is obfuscated, which
 
57
bounces, or which goes through an anti-spam service such as spamgourmet.com.
 
58
 
 
59
 
156
60
 
157
61
Creating a branch
158
 
=================
159
 
 
160
 
History is by default stored in the .bzr directory of the branch. In a
161
 
future version of Bazaar, there will be a facility to store it in a
162
 
separate repository, which may be remote.
163
 
 
164
 
We create a new branch by running ``bzr init`` in an existing directory::
 
62
==================
 
63
 
 
64
 
 
65
History is by default stored in the .bzr directory of the branch.
 
66
There will be a facility to store it in a separate repository, which
 
67
may be remote.  We create a new branch by running *bzr init* in
 
68
an existing directory::
165
69
 
166
70
    % mkdir tutorial
167
71
    % cd tutorial
168
72
    % ls -a
 
73
    ls -a
169
74
    ./  ../
170
75
    % pwd
171
76
    /home/mbp/work/bzr.test/tutorial
175
80
    ./  ../  .bzr/
176
81
    %
177
82
 
178
 
As with CVS, there are three classes of file: unknown, ignored, and
179
 
versioned.  The **add** command makes a file versioned: that is, changes
180
 
to it will be recorded by the system::
 
83
As for CVS, there are three classes of file: unknown, ignored, and
 
84
versioned.  The *add* command makes a file versioned: that is,
 
85
changes to it will be recorded by the system::
181
86
 
182
87
    % echo 'hello world' > hello.txt
183
88
    % bzr status
184
 
    unknown:
185
 
      hello.txt
186
 
    % bzr add hello.txt
187
 
    added hello.txt
188
 
    % bzr status
189
 
    added:
190
 
      hello.txt
191
 
 
192
 
 
193
 
If you add the wrong file, simply use ``bzr remove`` to make it
194
 
unversioned again.  This does not delete the working copy in this case,
195
 
though it may in others [2]_.
196
 
 
197
 
.. [2] ``bzr remove`` will remove the working copy if it is currently
198
 
   versioned, but has no changes from the last committed version.  You
199
 
   can force the file to always be kept with the ``--keep`` option to
200
 
   ``bzr remove``, or force it to always be deleted with ``--force``.
201
 
 
202
 
Branch locations
203
 
================
204
 
 
205
 
All history is stored in a branch, which is just an on-disk directory
206
 
containing control files.  By default there is no separate repository or
207
 
database as used in svn or svk. You can choose to create a repository if
208
 
you want to (see the ``bzr init-repo`` command). You may wish to do this
209
 
if you have very large branches, or many branches of a moderately sized
210
 
project.
211
 
 
212
 
You'll usually refer to branches on your computer's filesystem just by
213
 
giving the name of the directory containing the branch.  bzr also supports
214
 
accessing branches over http and sftp, for example::
215
 
 
216
 
    % bzr log http://bazaar-vcs.org/bzr/bzr.dev/
217
 
    % bzr log sftp://bazaar-vcs.org/bzr/bzr.dev/
218
 
 
219
 
By installing bzr plugins you can also access branches using the rsync
220
 
protocol.
221
 
 
222
 
See the `Publishing your branch`_ section for more about how to put your
223
 
branch at a given location.
 
89
    ?       hello.txt
 
90
    % bzr unknowns
 
91
    hello.txt
 
92
    % bzr add -v hello.txt
 
93
    A       hello.txt
 
94
    % bzr unknowns
 
95
 
 
96
 
 
97
If you add the wrong file, simply use ``bzr remove`` to make
 
98
it unversioned again.  This does not delete the working copy.
 
99
 
224
100
 
225
101
Reviewing changes
226
102
=================
227
103
 
228
 
Once you have completed some work, you will want to **commit** it to the
229
 
version history.  It is good to commit fairly often: whenever you get a
230
 
new feature working, fix a bug, or improve some code or documentation.
231
 
It's also a good practice to make sure that the code compiles and passes
232
 
its test suite before committing, to make sure that every revision is a
233
 
known-good state.  You can also review your changes, to make sure you're
234
 
committing what you intend to, and as a chance to rethink your work before
235
 
you permanently record it. 
236
 
 
237
 
Two bzr commands are particularly useful here: **status** and **diff**.  
238
 
 
239
 
bzr status
240
 
----------
241
 
 
242
 
The **status** command tells you what changes have been made to the
243
 
working directory since the last revision::
 
104
Once you have completed some work, you will want to *commit*
 
105
it to the version history.  It is good to commit fairly often:
 
106
whenever you get a new feature working, fix a bug, or improve some
 
107
code or documentation.  It's also a good practice to make sure that
 
108
the code compiles and passes its test suite before committing, to make
 
109
sure that every revision is a known-good state.  You can also review
 
110
your changes, to make sure you're committing what you intend to, and
 
111
as a chance to rethink your work before you permanently record it. 
 
112
 
 
113
Two bzr commands are particularly useful here: *status* and
 
114
*diff*.  The *status* command
 
115
shows a listing with one line per file, indicating whether it has been
 
116
Added, Deleted, Modified, or Renamed in the current revision.  Unknown
 
117
files are shown as '?'.  With the ``--all`` option, the status
 
118
command also shows unmodified versioned files as '.', and ignored
 
119
files as 'I'::
244
120
 
245
121
    % bzr status
246
 
    modified:
247
 
       foo
248
 
 
249
 
``bzr status`` hides "boring" files that are either unchanged or ignored.
250
 
The status command can optionally be given the name of some files or
251
 
directories to check.
252
 
 
253
 
bzr diff
254
 
--------
255
 
 
256
 
The **diff** command shows the full text of changes to all files as a
257
 
standard unified diff.  This can be piped through many programs such as
258
 
''patch'', ''diffstat'', ''filterdiff'' and ''colordiff''::
 
122
    A       hello.txt
 
123
 
 
124
The *diff* command shows the full text of changes to all
 
125
files as a standard unified diff.  This can be piped through many
 
126
programs such as ``patch``, ``diffstat``,
 
127
``filterdiff`` and ``colordiff``::
259
128
 
260
129
    % bzr diff
261
 
    === added file 'hello.txt'
262
 
    --- hello.txt   1970-01-01 00:00:00 +0000
263
 
    +++ hello.txt   2005-10-18 14:23:29 +0000
264
 
    @@ -0,0 +1,1 @@
 
130
    *** added file 'hello.txt'
 
131
    --- /dev/null 
 
132
    +++ hello.txt 
 
133
    @@ -1,0 +1,1 @@
265
134
    +hello world
266
135
 
267
 
 
268
 
With the ``-r`` option, the tree is compared to an earlier revision, or
269
 
the differences between two versions are shown::
270
 
 
271
 
    % bzr diff -r 1000..          # everything since r1000
272
 
    % bzr diff -r 1000..1100      # changes from 1000 to 1100
273
 
 
274
 
The ``--diff-options`` option causes bzr to run the external diff program,
275
 
passing options.  For example::
276
 
 
277
 
    % bzr diff --diff-options --side-by-side foo
278
 
 
279
 
Some projects prefer patches to show a prefix at the start of the path
280
 
for old and new files.  The ``--prefix`` option can be used to provide
281
 
such a prefix.
282
 
As a shortcut, ``bzr diff -p1`` produces a form that works with the 
283
 
command ``patch -p1``.
 
136
With the ``-r`` option, the tree is compared to an earlier
 
137
revision.
 
138
 
 
139
[TODO: options to run external diff; to get context diff or other
 
140
formats; to diff only selected files; to compare two historical
 
141
revisions.]
 
142
 
 
143
 
284
144
 
285
145
Committing changes
286
146
==================
287
147
 
288
 
When the working tree state is satisfactory, it can be **committed** to
289
 
the branch, creating a new revision holding a snapshot of that state.  
290
 
 
291
 
bzr commit
292
 
----------
293
 
 
294
 
The **commit** command takes a message describing the changes in the
295
 
revision.  It also records your userid, the current time and timezone, and
296
 
the inventory and contents of the tree.  The commit message is specified
297
 
by the ``-m`` or ``--message`` option. You can enter a multi-line commit
298
 
message; in most shells you can enter this just by leaving the quotes open
299
 
at the end of the line.
300
 
 
301
 
::
 
148
When the working tree state is satisfactory, it can be
 
149
*committed* to the branch, creating a new revision holding a
 
150
snapshot of that state.  
 
151
 
 
152
The ``commit`` command takes a message describing the changes
 
153
in the revision.  It also records your userid, the current time and
 
154
timezone, and the inventory and contents of the tree.  The commit
 
155
message is specified by the ``-m`` or ``--message`` option.
 
156
You can enter a multi-line commit message; in most shells you can
 
157
enter this just by leaving the quotes open at the end of the line. ::
302
158
 
303
159
    % bzr commit -m "added my first file"
304
160
 
305
 
You can also use the ``-F`` option to take the message from a file.  Some
306
 
people like to make notes for a commit message while they work, then
307
 
review the diff to make sure they did what they said they did.  (This file
308
 
can also be useful when you pick up your work after a break.)
309
 
 
310
 
Message from an editor
311
 
======================
312
 
 
313
 
If you use neither the ``-m`` nor the ``-F`` option then bzr will open an
314
 
editor for you to enter a message.  The editor to run is controlled by
315
 
your ``$VISUAL`` or ``$EDITOR`` environment variable, which can be overridden
316
 
by the ``editor`` setting in ``~/.bazaar/bazaar.conf``; ``$BZR_EDITOR`` will
317
 
override either of the above mentioned editor options.  If you quit the
318
 
editor without making any changes, the commit will be cancelled.
319
 
 
320
 
The file that is opened in the editor contains a horizontal line. The part
321
 
of the file below this line is included for information only, and will not
322
 
form part of the commit message. Below the separator is shown the list of
323
 
files that are changed in the commit. You should write your message above
324
 
the line, and then save the file and exit.
325
 
 
326
 
If you would like to see the diff that will be committed as you edit the
327
 
message you can use the ``--show-diff`` option to ``commit``. This will include
328
 
the diff in the editor when it is opened, below the separator and the
329
 
information about the files that will be committed. This means that you can
330
 
read it as you write the message, but the diff itself wont be seen in the
331
 
commit message when you have finished. If you would like parts to be
332
 
included in the message you can copy and paste them above the separator.
333
 
 
334
 
Selective commit
335
 
----------------
336
 
 
337
 
If you give file or directory names on the commit command line then only
338
 
the changes to those files will be committed.  For example::
339
 
 
340
 
    % bzr commit -m "documentation fix" commit.py
341
 
 
342
 
By default bzr always commits all changes to the tree, even if run from a
343
 
subdirectory.  To commit from only the current directory down, use::
344
 
 
345
 
    % bzr commit .
 
161
[TODO: commit message interactively, through an editor or from a
 
162
file.]
 
163
 
 
164
[TODO: commit only selected files, including renamed/added/deleted
 
165
files.]
 
166
 
346
167
 
347
168
 
348
169
Removing uncommitted changes
349
170
============================
350
171
 
351
172
If you've made some changes and don't want to keep them, use the
352
 
**revert** command to go back to the previous head version.  It's a good
353
 
idea to use ``bzr diff`` first to see what will be removed. By default the
354
 
revert command reverts the whole tree; if file or directory names are
355
 
given then only those ones will be affected. ``bzr revert`` also clears the
356
 
list of pending merges revisions.
 
173
``revert`` command to go back to the previous head version.  It's a
 
174
good idea to use ``bzr diff`` first to see what will be removed. 
 
175
By default the revert command reverts the whole tree; if file or
 
176
directory names are given then only those ones will be affected.
 
177
revert also clears the list of pending merges revisions.
 
178
 
 
179
 
 
180
 
 
181
 
357
182
 
358
183
Ignoring files
359
184
==============
360
185
 
361
 
Many source trees contain some files that do not need to be versioned,
362
 
such as editor backups, object or bytecode files, and built programs.  You
363
 
can simply not add them, but then they'll always crop up as unknown files.
364
 
You can also tell bzr to ignore these files by adding them to a file
365
 
called ``.bzrignore`` at the top of the tree.
 
186
Many source trees contain some files that do not need to be
 
187
versioned, such as editor backups, object or bytecode files, and built
 
188
programs.  You can simply not add them, but then they'll always crop
 
189
up as unknown files.  You can also tell bzr to ignore these files by
 
190
adding them to a file called ``.bzrignore`` at the top of the
 
191
tree.
366
192
 
367
 
This file contains a list of file wildcards (or "globs"), one per line.
368
 
Typical contents are like this::
 
193
This file contains a list of file wildcards (or "globs"), one
 
194
per line.  Typical contents are like this::
369
195
 
370
196
    *.o
371
197
    *~
372
198
    *.tmp
373
199
    *.py[co]
374
200
 
375
 
If a glob contains a slash, it is matched against the whole path from the
376
 
top of the tree; otherwise it is matched against only the filename.  So
377
 
the previous example ignores files with extension ``.o`` in all
378
 
subdirectories, but this example ignores only ``config.h`` at the top level
379
 
and HTML files in ``doc/``::
 
201
If a glob contains a slash, it is matched against the whole path
 
202
from the top of the tree; otherwise it is matched against only the
 
203
filename.  So the previous example ignores ``*.o`` in all
 
204
subdirectories, but this example ignores only config.h at the top
 
205
level and HTML files in ``doc/``::
380
206
 
381
207
    ./config.h
382
208
    doc/*.html
383
209
 
384
 
To get a list of which files are ignored and what pattern they matched,
385
 
use ``bzr ignored``::
 
210
To get a list of which files are ignored and what pattern they matched, use ``bzr ignored``::
386
211
 
387
212
    % bzr ignored
388
 
    config.h                 ./config.h
389
 
    configure.in~            *~
390
 
 
391
 
It is OK to have either an ignore pattern match a versioned file, or to
392
 
add an ignored file.  Ignore patterns have no effect on versioned files;
393
 
they only determine whether unversioned files are reported as unknown or
394
 
ignored.
395
 
 
396
 
The ``.bzrignore`` file should normally be versioned, so that new copies
397
 
of the branch see the same patterns::
 
213
    config.h                                           ./config.h
 
214
    configure.in~                                      *~
 
215
 
 
216
It is OK to have an ignore pattern match a versioned file, or to
 
217
add an ignored file.  Ignore patterns have no effect on versioned
 
218
files; they only determine whether unversioned files are reported as
 
219
unknown or ignored.
 
220
 
 
221
The ``.bzrignore`` file should normally be versioned, so that new
 
222
copies of the branch see the same patterns::
398
223
 
399
224
    % bzr add .bzrignore
400
225
    % bzr commit -m "Add ignore patterns"
401
226
 
402
227
 
403
 
Global Ignores
404
 
--------------
405
 
 
406
 
There are some ignored files which are not project specific, but more user
407
 
specific. Things like editor temporary files, or personal temporary files.
408
 
Rather than add these ignores to every project, bzr supports a global
409
 
ignore file in ``~/.bazaar/ignore`` [1]_. It has the same syntax as the
410
 
per-project ignore file.
411
 
 
412
 
 
413
228
Examining history
414
229
=================
415
230
 
416
231
bzr log
417
232
-------
418
233
 
419
 
The ``bzr log`` command shows a list of previous revisions. The ``bzr log
420
 
--forward`` command does the same in chronological order to get most
421
 
recent revisions printed at last.
422
 
 
423
 
As with ``bzr diff``, ``bzr log`` supports the ``-r`` argument::
424
 
 
425
 
    % bzr log -r 1000..          # Revision 1000 and everything after it
426
 
    % bzr log -r ..1000          # Everything up to and including r1000
427
 
    % bzr log -r 1000..1100      # changes from 1000 to 1100
428
 
    % bzr log -r 1000            # The changes in only revision 1000
 
234
The ``log`` command shows a list of previous revisions.
429
235
 
430
236
 
431
237
Branch statistics
432
238
=================
433
239
 
434
 
The ``bzr info`` command shows some summary information about the working
435
 
tree and the branch history.  
 
240
The ``bzr info`` command shows some summary information about
 
241
the working tree and the branch history.  
436
242
 
437
243
 
438
244
Versioning directories
439
245
======================
440
246
 
441
 
bzr versions files and directories in a way that can keep track of renames
442
 
and intelligently merge them::
 
247
bzr versions files and directories in a way that can keep track of
 
248
renames and intelligently merge them::
443
249
 
444
250
    % mkdir src
445
251
    % echo 'int main() {}' > src/simple.c
446
252
    % bzr add src
447
 
    added src
448
 
    added src/simple.c
449
 
    % bzr status
450
 
    added:
451
 
      src/
452
 
      src/simple.c
 
253
    % bzr status
 
254
    A       src/
 
255
    ?       src/simple.c
 
256
    % bzr add src/simple.c
 
257
    % bzr status
 
258
    A       src/
 
259
    A       src/simple.c
453
260
 
454
261
 
455
262
Deleting and removing files
456
263
===========================
457
264
 
458
 
You can delete files or directories by just deleting them from the working
459
 
directory.  This is a bit different to CVS, which requires that you also
460
 
do ``cvs remove``.
461
 
 
462
 
    ``bzr remove`` makes the file un-versioned, but may or may not delete
463
 
    the working copy [2]_.  This is useful when you add the wrong file,
464
 
    or decide that a file should actually not be versioned. 
465
 
 
466
 
::
 
265
You can delete files or directories by just deleting them from the
 
266
working directory.  This is a bit different to CVS, which requires
 
267
that you also do *cvs remove*.
 
268
 
 
269
*bzr remove* makes the file un-versioned, but does not
 
270
delete the working copy.  This is useful when you add the wrong file,
 
271
or decide that a file should actually not be versioned. ::
467
272
 
468
273
    % rm -r src
469
274
    % bzr remove -v hello.txt
470
275
    ?       hello.txt
471
276
    % bzr status
472
 
    removed:
473
 
      hello.txt
474
 
      src/
475
 
      src/simple.c
476
 
    unknown:
477
 
      hello.txt
478
 
 
479
 
If you remove the wrong file by accident, you can use ``bzr revert`` to
480
 
restore it.
 
277
    ?       hello.txt
 
278
    D       src/
 
279
    D       src/simple.c
481
280
 
482
281
 
483
282
Branching
484
283
=========
485
284
 
486
 
Often rather than starting your own project, you will want to submit a
487
 
change to an existing project.  To do this, you'll need to get a copy of
488
 
the existing branch.  Because this new copy is potentially a new branch,
489
 
the command is called **branch**::
 
285
Often rather than starting your own project, you will want to
 
286
submit a change to an existing project.  You can get a copy of an
 
287
existing branch by copying its directory, expanding a tarball, or by a
 
288
remote copy using something like rsync.  You can also use bzr to fetch
 
289
a copy.  Because this new copy is potentially a new branch, the
 
290
command is called *branch*::
490
291
 
491
 
    % bzr branch http://bazaar-vcs.org/bzr/bzr.dev 
 
292
    % bzr branch http://bazaar-ng.org/bzr/bzr.dev
492
293
    % cd bzr.dev
493
294
 
494
 
This copies down the complete history of this branch, so we can do all
495
 
operations on it locally: log, annotate, making and merging branches.
496
 
There will be an option to get only part of the history if you wish.
497
 
 
498
 
You can also get a copy of an existing branch by copying its directory,
499
 
expanding a tarball, or by a remote copy using something like rsync.
 
295
This copies down the complete history of this branch, so we can
 
296
do all operations on it locally: log, annotate, making and merging
 
297
branches.  There will be an option to get only part of the history if
 
298
you wish.
 
299
 
 
300
 
500
301
 
501
302
Following upstream changes
502
303
==========================
503
304
 
504
 
You can stay up-to-date with the parent branch by "pulling" in their
505
 
changes::
 
305
You can stay up-to-date with the parent branch by *pulling*
 
306
in their changes::
506
307
 
507
308
    % bzr pull
508
309
 
509
 
After this change, the local directory will be a mirror of the source. This
510
 
includes the ''revision-history'' - which is a list of the commits done in 
511
 
this branch, rather than merged from other branches.
512
 
 
513
 
This command only works if your local (destination) branch is either an
514
 
older copy of the parent branch with no new commits of its own, or if the
515
 
most recent commit in your local branch has been merged into the parent
516
 
branch.
517
 
 
518
 
Merging from related branches
519
 
=============================
520
 
 
521
 
If two branches have diverged (both have unique changes) then ``bzr
522
 
merge`` is the appropriate command to use. Merge will automatically
523
 
calculate the changes that exist in the branch you're merging from that
524
 
are not in your branch and attempt to apply them in your branch.
525
 
 
526
 
::
527
 
 
528
 
  % bzr merge URL
529
 
 
530
 
 
531
 
If there is a conflict during a merge, 3 files with the same basename
532
 
are created. The filename of the common base is appended with ".BASE",
533
 
the filename of the file containing your changes is appended with
534
 
".THIS" and the filename with the changes from the other tree is
535
 
appended with ".OTHER".  Using a program such as kdiff3, you can now
536
 
comfortably merge them into one file.  In order to commit you have to
537
 
rename the merged file (".THIS") to the original file name.  To
538
 
complete the conflict resolution you must use the resolve command,
539
 
which will remove the ".OTHER" and ".BASE" files.  As long as there
540
 
exist files with .BASE, .THIS or .OTHER the commit command will
541
 
report an error.
542
 
 
543
 
::
544
 
 
545
 
  % kdiff3 file.BASE file.OTHER file.THIS
546
 
  % mv file.THIS file
547
 
  % bzr resolve file
548
 
 
549
 
[**TODO**: explain conflict markers within files]
550
 
 
551
 
 
552
 
Publishing your branch
553
 
======================
554
 
 
555
 
You don't need a special server to publish a bzr branch, just a normal web
556
 
server.  Just mirror the files to your server, including the .bzr
557
 
directory.  One can push a branch (or the changes for a branch) by one of
558
 
the following three methods:
559
 
 
560
 
* The best method is to use bzr itself to do it.
561
 
 
562
 
  ::
563
 
 
564
 
    % bzr push sftp://servername.com/path/to/directory 
565
 
 
566
 
  (The destination directory must already exist unless the
567
 
  ``--create-prefix`` option is used.)
568
 
 
569
 
* Another option is the ``rspush`` plugin that comes with BzrTools, which
570
 
  uses rsync to push the changes to the revision history and the working
571
 
  tree.
572
 
 
573
 
You can also use copy the files around manually, by sending a tarball, or
574
 
using rsync, or other related file transfer methods.  This is usually
575
 
less safe than using ``push``, but may be faster or easier in some
576
 
situations.
577
 
 
578
 
Moving changes between trees 
579
 
============================
580
 
 
581
 
It happens to the best of us: sometimes you'll make changes in the wrong
582
 
tree.  Maybe because you've accidentally started work in the wrong directory,
583
 
maybe because as you're working, the change turns out to be bigger than you
584
 
expected, so you start a new branch for it.
585
 
 
586
 
To move your changes from one tree to another, use
587
 
 
588
 
::
589
 
 
590
 
  % cd NEWDIR
591
 
  % bzr merge --uncommitted OLDDIR
592
 
 
593
 
This will apply all of the uncommitted changes you made in OLDDIR to NEWDIR.
594
 
It will not apply committed changes, even if they could be applied to NEWDIR
595
 
with a regular merge.  The changes will remain in OLDDIR, but you can use ``bzr
596
 
revert OLDDIR`` to remove them, once you're satisfied with NEWDIR.
597
 
 
598
 
NEWDIR does not have to be a copy of OLDDIR, but they should be related.
599
 
The more different they are, the greater the chance of conflicts.
 
310
This only works if your local branch includes only changes from the
 
311
parent branch.  Otherwise, the branches are said to have *diverged*,
 
312
and they must be merged instead.