~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/tutorial.txt

  • Committer: Martin Pool
  • Date: 2005-06-22 06:37:43 UTC
  • Revision ID: mbp@sourcefrog.net-20050622063743-e395f04c4db8977f
- move old blackbox code from testbzr into bzrlib.selftest.blackbox

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.16, 2007-05
15
 
 
16
 
 
17
 
Introduction
18
 
============
19
 
 
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
 
There will be more in the future.
113
 
 
114
 
One function of a version control system is to keep track of who changed
115
 
what.  In a decentralized system, that requires an identifier for each
116
 
author that is globally unique.  Most people already have one of these: an
117
 
email address. Bzr is smart enough to automatically generate an email
118
 
address by looking up your username and hostname. If you don't like the
119
 
guess that Bazaar makes, then three options exist:
120
 
 
121
 
 1. Set an email address via ``bzr whoami``.  This is the simplest way.
122
 
 
123
 
    To set a global identity, use::
124
 
 
125
 
    % bzr whoami "Your Name <email@example.com>"
126
 
 
127
 
    If you'd like to use a different address for a specific branch, enter
128
 
    the branch folder and use::
129
 
 
130
 
    % bzr whoami --branch "Your Name <email@example.com>"
131
 
 
132
 
 #. Setting the email address in the ``~/.bazaar/bazaar.conf`` [1]_ by
133
 
    adding the following lines.  Please note that  ``[DEFAULT]`` is case
134
 
    sensitive::
135
 
 
136
 
        [DEFAULT]
137
 
        email=Your Name <email@isp.com>
138
 
 
139
 
    As above, you can override this settings on a branch by branch basis
140
 
    by creating a branch section in ``~/.bazaar/locations.conf`` and
141
 
    adding the following lines::
142
 
 
143
 
        [/the/path/to/the/branch]
144
 
        email=Your Name <email@isp.com>
145
 
 
146
 
 
147
 
 #. Overriding the two previous options by setting the global environment
148
 
    variable ``$BZR_EMAIL`` or ``$EMAIL`` (``$BZR_EMAIL`` will take
149
 
    precedence) to your full email address.
150
 
 
151
 
.. [1] On Windows, the users configuration files can be found in the
152
 
   application data directory. So instead of ``~/.bazaar/branch.conf``
153
 
   the configuration file can be found as: 
154
 
   ``C:\Documents and Settings\<username>\Application Data\Bazaar\2.0\branch.conf``.
155
 
   The same is true for ``locations.conf``, ``ignore``, and the
156
 
   ``plugins`` directory.
157
 
 
158
 
Creating a branch
159
 
=================
160
 
 
161
 
History is by default stored in the .bzr directory of the branch. In a
162
 
future version of Bazaar, there will be a facility to store it in a
163
 
separate repository, which may be remote.  We create a new branch by
164
 
running ``bzr init`` in an existing directory::
165
 
 
166
 
    % mkdir tutorial
167
 
    % cd tutorial
168
 
    % ls -a
169
 
    ./  ../
170
 
    % pwd
171
 
    /home/mbp/work/bzr.test/tutorial
172
 
    %
173
 
    % bzr init
174
 
    % ls -aF
175
 
    ./  ../  .bzr/
176
 
    %
177
 
 
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::
181
 
 
182
 
    % echo 'hello world' > hello.txt
183
 
    % 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.
224
 
 
225
 
Reviewing changes
226
 
=================
227
 
 
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::
244
 
 
245
 
    % 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''::
259
 
 
260
 
    % 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 @@
265
 
    +hello world
266
 
 
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``.
284
 
 
285
 
Committing changes
286
 
==================
287
 
 
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
 
::
302
 
 
303
 
    % bzr commit -m "added my first file"
304
 
 
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
 
Selective commit
321
 
----------------
322
 
 
323
 
If you give file or directory names on the commit command line then only
324
 
the changes to those files will be committed.  For example::
325
 
 
326
 
    % bzr commit -m "documentation fix" commit.py
327
 
 
328
 
By default bzr always commits all changes to the tree, even if run from a
329
 
subdirectory.  To commit from only the current directory down, use::
330
 
 
331
 
    % bzr commit .
332
 
 
333
 
 
334
 
Removing uncommitted changes
335
 
============================
336
 
 
337
 
If you've made some changes and don't want to keep them, use the
338
 
**revert** command to go back to the previous head version.  It's a good
339
 
idea to use ``bzr diff`` first to see what will be removed. By default the
340
 
revert command reverts the whole tree; if file or directory names are
341
 
given then only those ones will be affected. ``bzr revert`` also clears the
342
 
list of pending merges revisions.
343
 
 
344
 
Ignoring files
345
 
==============
346
 
 
347
 
Many source trees contain some files that do not need to be versioned,
348
 
such as editor backups, object or bytecode files, and built programs.  You
349
 
can simply not add them, but then they'll always crop up as unknown files.
350
 
You can also tell bzr to ignore these files by adding them to a file
351
 
called ``.bzrignore`` at the top of the tree.
352
 
 
353
 
This file contains a list of file wildcards (or "globs"), one per line.
354
 
Typical contents are like this::
355
 
 
356
 
    *.o
357
 
    *~
358
 
    *.tmp
359
 
    *.py[co]
360
 
 
361
 
If a glob contains a slash, it is matched against the whole path from the
362
 
top of the tree; otherwise it is matched against only the filename.  So
363
 
the previous example ignores files with extension ``.o`` in all
364
 
subdirectories, but this example ignores only ``config.h`` at the top level
365
 
and HTML files in ``doc/``::
366
 
 
367
 
    ./config.h
368
 
    doc/*.html
369
 
 
370
 
To get a list of which files are ignored and what pattern they matched,
371
 
use ``bzr ignored``::
372
 
 
373
 
    % bzr ignored
374
 
    config.h                 ./config.h
375
 
    configure.in~            *~
376
 
 
377
 
It is OK to have either an ignore pattern match a versioned file, or to
378
 
add an ignored file.  Ignore patterns have no effect on versioned files;
379
 
they only determine whether unversioned files are reported as unknown or
380
 
ignored.
381
 
 
382
 
The ``.bzrignore`` file should normally be versioned, so that new copies
383
 
of the branch see the same patterns::
384
 
 
385
 
    % bzr add .bzrignore
386
 
    % bzr commit -m "Add ignore patterns"
387
 
 
388
 
 
389
 
Global Ignores
390
 
--------------
391
 
 
392
 
There are some ignored files which are not project specific, but more user
393
 
specific. Things like editor temporary files, or personal temporary files.
394
 
Rather than add these ignores to every project, bzr supports a global
395
 
ignore file in ``~/.bazaar/ignore`` [1]_. It has the same syntax as the
396
 
per-project ignore file.
397
 
 
398
 
 
399
 
Examining history
400
 
=================
401
 
 
402
 
bzr log
403
 
-------
404
 
 
405
 
The ``bzr log`` command shows a list of previous revisions. The ``bzr log
406
 
--forward`` command does the same in chronological order to get most
407
 
recent revisions printed at last.
408
 
 
409
 
As with ``bzr diff``, ``bzr log`` supports the ``-r`` argument::
410
 
 
411
 
    % bzr log -r 1000..          # Revision 1000 and everything after it
412
 
    % bzr log -r ..1000          # Everything up to and including r1000
413
 
    % bzr log -r 1000..1100      # changes from 1000 to 1100
414
 
    % bzr log -r 1000            # The changes in only revision 1000
415
 
 
416
 
 
417
 
Branch statistics
418
 
=================
419
 
 
420
 
The ``bzr info`` command shows some summary information about the working
421
 
tree and the branch history.  
422
 
 
423
 
 
424
 
Versioning directories
425
 
======================
426
 
 
427
 
bzr versions files and directories in a way that can keep track of renames
428
 
and intelligently merge them::
429
 
 
430
 
    % mkdir src
431
 
    % echo 'int main() {}' > src/simple.c
432
 
    % bzr add src
433
 
    added src
434
 
    added src/simple.c
435
 
    % bzr status
436
 
    added:
437
 
      src/
438
 
      src/simple.c
439
 
 
440
 
 
441
 
Deleting and removing files
442
 
===========================
443
 
 
444
 
You can delete files or directories by just deleting them from the working
445
 
directory.  This is a bit different to CVS, which requires that you also
446
 
do ``cvs remove``.
447
 
 
448
 
    ``bzr remove`` makes the file un-versioned, but may or may not delete
449
 
    the working copy [2]_.  This is useful when you add the wrong file,
450
 
    or decide that a file should actually not be versioned. 
451
 
 
452
 
::
453
 
 
454
 
    % rm -r src
455
 
    % bzr remove -v hello.txt
456
 
    ?       hello.txt
457
 
    % bzr status
458
 
    removed:
459
 
      hello.txt
460
 
      src/
461
 
      src/simple.c
462
 
    unknown:
463
 
      hello.txt
464
 
 
465
 
If you remove the wrong file by accident, you can use ``bzr revert`` to
466
 
restore it.
467
 
 
468
 
 
469
 
Branching
470
 
=========
471
 
 
472
 
Often rather than starting your own project, you will want to submit a
473
 
change to an existing project.  To do this, you'll need to get a copy of
474
 
the existing branch.  Because this new copy is potentially a new branch,
475
 
the command is called **branch**::
476
 
 
477
 
    % bzr branch http://bazaar-vcs.org/bzr/bzr.dev 
478
 
    % cd bzr.dev
479
 
 
480
 
This copies down the complete history of this branch, so we can do all
481
 
operations on it locally: log, annotate, making and merging branches.
482
 
There will be an option to get only part of the history if you wish.
483
 
 
484
 
You can also get a copy of an existing branch by copying its directory,
485
 
expanding a tarball, or by a remote copy using something like rsync.
486
 
 
487
 
Following upstream changes
488
 
==========================
489
 
 
490
 
You can stay up-to-date with the parent branch by "pulling" in their
491
 
changes::
492
 
 
493
 
    % bzr pull
494
 
 
495
 
After this change, the local directory will be a mirror of the source. This
496
 
includes the ''revision-history'' - which is a list of the commits done in 
497
 
this branch, rather than merged from other branches.
498
 
 
499
 
This command only works if your local (destination) branch is either an
500
 
older copy of the parent branch with no new commits of its own, or if the
501
 
most recent commit in your local branch has been merged into the parent
502
 
branch.
503
 
 
504
 
Merging from related branches
505
 
=============================
506
 
 
507
 
If two branches have diverged (both have unique changes) then ``bzr
508
 
merge`` is the appropriate command to use. Merge will automatically
509
 
calculate the changes that exist in the branch you're merging from that
510
 
are not in your branch and attempt to apply them in your branch.
511
 
 
512
 
::
513
 
 
514
 
  % bzr merge URL
515
 
 
516
 
 
517
 
If there is a conflict during a merge, 3 files with the same basename
518
 
are created. The filename of the common base is appended with ".BASE",
519
 
the filename of the file containing your changes is appended with
520
 
".THIS" and the filename with the changes from the other tree is
521
 
appended with ".OTHER".  Using a program such as kdiff3, you can now
522
 
comfortably merge them into one file.  In order to commit you have to
523
 
rename the merged file (".THIS") to the original file name.  To
524
 
complete the conflict resolution you must use the resolve command,
525
 
which will remove the ".OTHER" and ".BASE" files.  As long as there
526
 
exist files with .BASE, .THIS or .OTHER the commit command will
527
 
report an error.
528
 
 
529
 
::
530
 
 
531
 
  % kdiff3 file.BASE file.OTHER file.THIS
532
 
  % mv file.THIS file
533
 
  % bzr resolve file
534
 
 
535
 
[**TODO**: explain conflict markers within files]
536
 
 
537
 
 
538
 
Publishing your branch
539
 
======================
540
 
 
541
 
You don't need a special server to publish a bzr branch, just a normal web
542
 
server.  Just mirror the files to your server, including the .bzr
543
 
directory.  One can push a branch (or the changes for a branch) by one of
544
 
the following three methods:
545
 
 
546
 
* The best method is to use bzr itself to do it.
547
 
 
548
 
  ::
549
 
 
550
 
    % bzr push sftp://servername.com/path/to/directory 
551
 
 
552
 
  (The destination directory must already exist unless the
553
 
  ``--create-prefix`` option is used.)
554
 
 
555
 
* Another option is the ``rspush`` plugin that comes with BzrTools, which
556
 
  uses rsync to push the changes to the revision history and the working
557
 
  tree.
558
 
 
559
 
You can also use copy the files around manually, by sending a tarball, or
560
 
using rsync, or other related file transfer methods.  This is usually
561
 
less safe than using ``push``, but may be faster or easier in some
562
 
situations.
563
 
 
564
 
Moving changes between trees 
565
 
============================
566
 
 
567
 
It happens to the best of us: sometimes you'll make changes in the wrong
568
 
tree.  Maybe because you've accidentally started work in the wrong directory,
569
 
maybe because as you're working, the change turns out to be bigger than you
570
 
expected, so you start a new branch for it.
571
 
 
572
 
To move your changes from one tree to another, use
573
 
 
574
 
::
575
 
 
576
 
  % cd NEWDIR
577
 
  % bzr merge --uncommitted OLDDIR
578
 
 
579
 
This will apply all of the uncommitted changes you made in OLDDIR to NEWDIR.
580
 
It will not apply committed changes, even if they could be applied to NEWDIR
581
 
with a regular merge.  The changes will remain in OLDDIR, but you can use ``bzr
582
 
revert OLDDIR`` to remove them, once you're satisfied with NEWDIR.
583
 
 
584
 
NEWDIR does not have to be a copy of OLDDIR, but they should be related.
585
 
The more different they are, the greater the chance of conflicts.