~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/tutorial.txt

  • Committer: mbp at sourcefrog
  • Date: 2005-04-08 05:38:42 UTC
  • Revision ID: mbp@sourcefrog.net-20050408053842-9bd97f96de87d9185583b310
more experiments with http get

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.8, 2006-04
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 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 developer can
94
 
take the modifications in one branch of software and apply them to
95
 
another, related, branch -- even if those changes exist in a branch owned
96
 
by somebody else. This allows developers to cooperate without giving write
97
 
access to 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
 
 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
 
 1. Setting the email address in the
132
 
 ``~/.bazaar/bazaar.conf`` [1]_ by adding the following lines. Please note that
133
 
 ``[DEFAULT]`` is case 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 by
139
 
 creating a branch section in ``~/.bazaar/locations.conf`` and adding the
140
 
 following lines::
141
 
 
142
 
    [/the/directory/to/the/branch]
143
 
    email=Your Name <email@isp.com>
144
 
 
145
 
 1. Overriding the two previous options by setting the global environment
146
 
 variable ``$BZREMAIL`` or ``$EMAIL`` (``$BZREMAIL`` will take precedence) 
147
 
 to your full email address.
148
 
 
149
 
.. [1] On Windows, the users configuration files can be found in the
150
 
   application data directory. So instead of ``~/.bazaar/branch.conf``
151
 
   the configuration file can be found as: 
152
 
   ``C:\Documents and Settings\<username>\Application Data\Bazaar\2.0\branch.conf``.
153
 
   The same is true for ``locations.conf``, ``ignore``, and the
154
 
   ``plugins`` directory.
155
 
 
156
 
Creating a branch
157
 
=================
158
 
 
159
 
History is by default stored in the .bzr directory of the branch. There
160
 
will be a facility to store it in a separate repository, which may be
161
 
remote.  We create a new branch by running **bzr init** in an existing
162
 
directory::
163
 
 
164
 
    % mkdir tutorial
165
 
    % cd tutorial
166
 
    % ls -a
167
 
    ./  ../
168
 
    % pwd
169
 
    /home/mbp/work/bzr.test/tutorial
170
 
    %
171
 
    % bzr init
172
 
    % ls -aF
173
 
    ./  ../  .bzr/
174
 
    %
175
 
 
176
 
As for CVS, there are three classes of file: unknown, ignored, and
177
 
versioned.  The **add** command makes a file versioned: that is, changes
178
 
to it will be recorded by the system::
179
 
 
180
 
    % echo 'hello world' > hello.txt
181
 
    % bzr status
182
 
    unknown:
183
 
      hello.txt
184
 
    % bzr unknowns
185
 
    hello.txt
186
 
    % bzr add hello.txt
187
 
    added hello.txt
188
 
    % bzr unknowns
189
 
 
190
 
 
191
 
If you add the wrong file, simply use **bzr remove** to make it
192
 
unversioned again.  This does not delete the working copy.
193
 
 
194
 
Branch locations
195
 
================
196
 
 
197
 
All history is stored in a branch, which is just an on-disk directory
198
 
containing control files.  By default there is no separate repository or
199
 
database as used in svn or svk. You can choose to create a repository if
200
 
you want to (see the **bzr init-repo** command). You may wish to do this
201
 
if you have very large branches, or many branches of a moderate sized
202
 
project.
203
 
 
204
 
You'll usually refer to branches on your computer's filesystem just by
205
 
giving the name of the directory containing the branch.  bzr also supports
206
 
accessing branches over http, for example::
207
 
 
208
 
    % bzr log http://bazaar-vcs.org/bzr/bzr.dev/
209
 
 
210
 
By installing bzr plugins you can also access branches over the sftp or
211
 
rsync protocols.
212
 
 
213
 
Reviewing changes
214
 
=================
215
 
 
216
 
Once you have completed some work, you will want to **commit** it to the
217
 
version history.  It is good to commit fairly often: whenever you get a
218
 
new feature working, fix a bug, or improve some code or documentation.
219
 
It's also a good practice to make sure that the code compiles and passes
220
 
its test suite before committing, to make sure that every revision is a
221
 
known-good state.  You can also review your changes, to make sure you're
222
 
committing what you intend to, and as a chance to rethink your work before
223
 
you permanently record it. 
224
 
 
225
 
Two bzr commands are particularly useful here: **status** and **diff**.  
226
 
 
227
 
bzr status
228
 
----------
229
 
 
230
 
The **status** command tells you what changes have been made to the
231
 
working directory since the last revision::
232
 
 
233
 
    % bzr status
234
 
    modified:
235
 
       foo
236
 
 
237
 
By default **bzr status** hides "boring" files that are either unchanged
238
 
or ignored.  To see them too, use the --all option.  The status command
239
 
can optionally be given the name of some files or directories to check.
240
 
 
241
 
bzr diff
242
 
--------
243
 
 
244
 
The **diff** command shows the full text of changes to all files as a
245
 
standard unified diff.  This can be piped through many programs such as
246
 
''patch'', ''diffstat'', ''filterdiff'' and ''colordiff''::
247
 
 
248
 
    % bzr diff
249
 
    *** added file 'hello.txt'
250
 
    --- /dev/null 
251
 
    +++ hello.txt 
252
 
    @@ -1,0 +1,1 @@
253
 
    +hello world
254
 
 
255
 
 
256
 
With the ''-r'' option, the tree is compared to an earlier revision, or
257
 
the differences between two versions are shown::
258
 
 
259
 
    % bzr diff -r 1000..          # everything since r1000
260
 
    % bzr diff -r 1000..1100      # changes from 1000 to 1100
261
 
 
262
 
The --diff-options option causes bzr to run the external diff program,
263
 
passing options.  For example::
264
 
 
265
 
    % bzr diff --diff-options --side-by-side foo
266
 
 
267
 
Some projects prefer patches to show a prefix at the start of the path for
268
 
old and new files.  The --prefix option can be used to provide such a prefix. 
269
 
As a shortcut, ``bzr diff -p1`` produces a form that works with the 
270
 
command ``patch -p1``.
271
 
 
272
 
Committing changes
273
 
==================
274
 
 
275
 
When the working tree state is satisfactory, it can be **committed** to
276
 
the branch, creating a new revision holding a snapshot of that state.  
277
 
 
278
 
bzr commit
279
 
----------
280
 
 
281
 
The **commit** command takes a message describing the changes in the
282
 
revision.  It also records your userid, the current time and timezone, and
283
 
the inventory and contents of the tree.  The commit message is specified
284
 
by the ''-m'' or ''--message'' option. You can enter a multi-line commit
285
 
message; in most shells you can enter this just by leaving the quotes open
286
 
at the end of the line.
287
 
 
288
 
::
289
 
 
290
 
    % bzr commit -m "added my first file"
291
 
 
292
 
You can also use the -F option to take the message from a file.  Some
293
 
people like to make notes for a commit message while they work, then
294
 
review the diff to make sure they did what they said they did.  (This file
295
 
can also be useful when you pick up your work after a break.)
296
 
 
297
 
Message from an editor
298
 
======================
299
 
 
300
 
If you use neither the `-m` nor the `-F` option then bzr will open an
301
 
editor for you to enter a message.  The editor to run is controlled by
302
 
your `$VISUAL` or `$EDITOR` environment variable, which can be overridden
303
 
by the `editor` setting in to ~/.bazaar/bazaar.conf; `$BZR_EDITOR` will
304
 
override either of the above mentioned editor options.  If you quit the
305
 
editor without making any changes, the commit will be cancelled.
306
 
 
307
 
Selective commit
308
 
----------------
309
 
 
310
 
If you give file or directory names on the commit command line then only
311
 
the changes to those files will be committed.  For example::
312
 
 
313
 
    % bzr commit -m "documentation fix" commit.py
314
 
 
315
 
By default bzr always commits all changes to the tree, even if run from a
316
 
subdirectory.  To commit from only the current directory down, use::
317
 
 
318
 
    % bzr commit .
319
 
 
320
 
 
321
 
Removing uncommitted changes
322
 
============================
323
 
 
324
 
If you've made some changes and don't want to keep them, use the
325
 
**revert** command to go back to the previous head version.  It's a good
326
 
idea to use **bzr diff** first to see what will be removed. By default the
327
 
revert command reverts the whole tree; if file or directory names are
328
 
given then only those ones will be affected. **revert** also clears the
329
 
list of pending merges revisions.
330
 
 
331
 
Ignoring files
332
 
==============
333
 
 
334
 
Many source trees contain some files that do not need to be versioned,
335
 
such as editor backups, object or bytecode files, and built programs.  You
336
 
can simply not add them, but then they'll always crop up as unknown files.
337
 
You can also tell bzr to ignore these files by adding them to a file
338
 
called ''.bzrignore'' at the top of the tree.
339
 
 
340
 
This file contains a list of file wildcards (or "globs"), one per line.
341
 
Typical contents are like this::
342
 
 
343
 
    *.o
344
 
    *~
345
 
    *.tmp
346
 
    *.py[co]
347
 
 
348
 
If a glob contains a slash, it is matched against the whole path from the
349
 
top of the tree; otherwise it is matched against only the filename.  So
350
 
the previous example ignores files with extension ``.o`` in all
351
 
subdirectories, but this example ignores only config.h at the top level
352
 
and HTML files in ``doc/``::
353
 
 
354
 
    ./config.h
355
 
    doc/*.html
356
 
 
357
 
To get a list of which files are ignored and what pattern they matched,
358
 
use ''bzr ignored''::
359
 
 
360
 
    % bzr ignored
361
 
    config.h                 ./config.h
362
 
    configure.in~            *~
363
 
 
364
 
It is OK to have either an ignore pattern match a versioned file, or to
365
 
add an ignored file.  Ignore patterns have no effect on versioned files;
366
 
they only determine whether unversioned files are reported as unknown or
367
 
ignored.
368
 
 
369
 
The ``.bzrignore`` file should normally be versioned, so that new copies
370
 
of the branch see the same patterns::
371
 
 
372
 
    % bzr add .bzrignore
373
 
    % bzr commit -m "Add ignore patterns"
374
 
 
375
 
 
376
 
Global Ignores
377
 
--------------
378
 
 
379
 
There are some ignored files which are not project specific, but more user
380
 
specific. Things like editor temporary files, or personal temporary files.
381
 
Rather than add these ignores to every project, bzr supports a global
382
 
ignore file in ``~/.bazaar/ignore`` [1]_. It has the same syntax as the
383
 
per-project ignore file.
384
 
 
385
 
 
386
 
Examining history
387
 
=================
388
 
 
389
 
bzr log
390
 
-------
391
 
 
392
 
The **bzr log** command shows a list of previous revisions. The **bzr log
393
 
--forward** command does the same in chronological order to get most
394
 
recent revisions printed at last.
395
 
 
396
 
As with bzr diff, bzr log supports the -r argument::
397
 
 
398
 
    % bzr log -r 1000..          # Revision 1000 and everything after it
399
 
    % bzr log -r ..1000          # Everything up to and including r1000
400
 
    % bzr log -r 1000..1100      # changes from 1000 to 1100
401
 
    % bzr log -r 1000            # The changes in only revision 1000
402
 
 
403
 
 
404
 
Branch statistics
405
 
=================
406
 
 
407
 
The **bzr info** command shows some summary information about the working
408
 
tree and the branch history.  
409
 
 
410
 
 
411
 
Versioning directories
412
 
======================
413
 
 
414
 
bzr versions files and directories in a way that can keep track of renames
415
 
and intelligently merge them::
416
 
 
417
 
    % mkdir src
418
 
    % echo 'int main() {}' > src/simple.c
419
 
    % bzr add src
420
 
    added src
421
 
    added src/simple.c
422
 
    % bzr status
423
 
    added:
424
 
      src/
425
 
      src/simple.c
426
 
 
427
 
 
428
 
Deleting and removing files
429
 
===========================
430
 
 
431
 
You can delete files or directories by just deleting them from the working
432
 
directory.  This is a bit different to CVS, which requires that you also
433
 
do **cvs remove**.
434
 
 
435
 
    **bzr remove** makes the file un-versioned, but does not delete
436
 
    the working copy.  This is useful when you add the wrong file, or decide
437
 
    that a file should actually not be versioned. 
438
 
 
439
 
::
440
 
 
441
 
    % rm -r src
442
 
    % bzr remove -v hello.txt
443
 
    ?       hello.txt
444
 
    % bzr status
445
 
    removed:
446
 
      hello.txt
447
 
      src/
448
 
      src/simple.c
449
 
    unknown:
450
 
      hello.txt
451
 
 
452
 
If you remove the wrong file by accident, you can use **bzr revert** to
453
 
restore it.
454
 
 
455
 
 
456
 
Branching
457
 
=========
458
 
 
459
 
Often rather than starting your own project, you will want to submit a
460
 
change to an existing project.  You can get a copy of an existing branch
461
 
by copying its directory, expanding a tarball, or by a remote copy using
462
 
something like rsync.  You can also use bzr to fetch a copy.  Because this
463
 
new copy is potentially a new branch, the command is called *branch*::
464
 
 
465
 
    % bzr branch http://bazaar-vcs.org/bzr/bzr.dev 
466
 
    % cd bzr.dev
467
 
 
468
 
This copies down the complete history of this branch, so we can do all
469
 
operations on it locally: log, annotate, making and merging branches.
470
 
There will be an option to get only part of the history if you wish.
471
 
 
472
 
Following upstream changes
473
 
==========================
474
 
 
475
 
You can stay up-to-date with the parent branch by "pulling" in their
476
 
changes::
477
 
 
478
 
    % bzr pull
479
 
 
480
 
After this change, the local directory will be a mirror of the source. This
481
 
includes the ''revision-history'' - which is a list of the commits done in 
482
 
this branch, rather than merged from other branches.
483
 
 
484
 
This command only works if your local (destination) branch is either an
485
 
older copy of the parent branch with no new commits of its own, or if the
486
 
most recent commit in your local branch has been merged into the parent
487
 
branch.
488
 
 
489
 
Merging from related branches
490
 
=============================
491
 
 
492
 
If two branches have diverged (both have unique changes) then **bzr
493
 
merge** is the appropriate command to use. Merge will automatically
494
 
calculate the changes that exist in the branch you're merging from that
495
 
are not in your branch and attempt to apply them in your branch.
496
 
 
497
 
::
498
 
 
499
 
  % bzr merge URL
500
 
 
501
 
 
502
 
If there is a conflict during a merge, 3 files with the same basename are
503
 
created. The filename of the common base is appended with .BASE, the
504
 
filename of the file containing your changes is appended .THIS and the
505
 
filename with the changes from the other tree is appended .OTHER.
506
 
Using a program such as kdiff3, you can now comfortably merge them into
507
 
one file. To commit you have to rename it to the original basename and
508
 
delete the other two files. As long as there exist files with .BASE, .THIS
509
 
or .OTHER the commit command will complain.
510
 
 
511
 
[**TODO**: explain conflict markers within files]
512
 
 
513
 
 
514
 
Publishing your branch
515
 
======================
516
 
 
517
 
You don't need a special server to publish a bzr branch, just a normal web
518
 
server.  Just mirror the files to your server, including the .bzr
519
 
directory.  One can push a branch (or the changes for a branch) by one of
520
 
the following three methods:
521
 
 
522
 
* Rsync:   rsync -avrz LOCALBRANCH  servername.com/this/directory/here
523
 
 
524
 
  (or any other tool for publishing a directory to a web site.)
525
 
 
526
 
* bzr push sftp://servername.com/this/directory/here 
527
 
 
528
 
  (The directory that must already exist)
529
 
 
530
 
* The rspush plugin that comes with BzrTools
531
 
 
532
 
 
533
 
Moving changes between trees 
534
 
============================
535
 
 
536
 
It happens to the best of us: sometimes you'll make changes in the wrong
537
 
tree.  Maybe because you've accidentally started work in the wrong directory,
538
 
maybe because as you're working, the change turns out to be bigger than you
539
 
expected, so you start a new branch for it.
540
 
 
541
 
To move your changes from one tree to another, use
542
 
 
543
 
::
544
 
 
545
 
  % cd NEWDIR
546
 
  % bzr merge --uncommitted OLDDIR
547
 
 
548
 
This will apply all of the uncommitted changes you made in OLDDIR to NEWDIR.
549
 
It will not apply committed changes, even if they could be applied to NEWDIR
550
 
with a regular merge.  The changes will remain in OLDDIR, but you can use **bzr
551
 
revert OLDDIR** to remove them, once you're satisfied with NEWDIR.
552
 
 
553
 
NEWDIR does not have to be a copy of OLDDIR, but they should be related.
554
 
The more different they are, the greater the chance of conflicts.