~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/tutorial.txt

  • Committer: John Arbash Meinel
  • Date: 2007-03-15 22:35:35 UTC
  • mto: This revision was merged to the branch mainline in revision 2363.
  • Revision ID: john@arbash-meinel.com-20070315223535-d3d4964oe1hc8zhg
Add an overzealous test, for Unicode support of _iter_changes.
For both knowns and unknowns.
And include a basic, if suboptimal, fix.
I would rather defer the decoding until we've determined that we are going to return the tuple.
There is still something broken with added files, but I'll get to that.

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 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 adding the following lines.
 
133
    Please note that  ``[DEFAULT]`` is case sensitive::
 
134
    [DEFAULT]
 
135
    email= Your Name <email@isp.com>
 
136
 
 
137
    As above, you can override this settings on a branch by branch basis by
 
138
    creating a branch section in ``~/.bazaar/locations.conf`` and adding the
 
139
    following lines::
 
140
    [/the/path/to/the/branch]
 
141
    email=Your Name <email@isp.com>
 
142
 
 
143
 
 
144
 #. Overriding the two previous options by setting the global environment
 
145
    variable ``$BZREMAIL`` or ``$EMAIL`` (``$BZREMAIL`` will take precedence) 
 
146
    to your full email address.
 
147
 
 
148
.. [1] On Windows, the users configuration files can be found in the
 
149
   application data directory. So instead of ``~/.bazaar/branch.conf``
 
150
   the configuration file can be found as: 
 
151
   ``C:\Documents and Settings\<username>\Application Data\Bazaar\2.0\branch.conf``.
 
152
   The same is true for ``locations.conf``, ``ignore``, and the
 
153
   ``plugins`` directory.
 
154
 
 
155
Creating a branch
 
156
=================
 
157
 
 
158
History is by default stored in the .bzr directory of the branch. In a
 
159
future version of Bazaar, there will be a facility to store it in a
 
160
separate repository, which may be remote.  We create a new branch by
 
161
running ``bzr init`` in an existing directory::
 
162
 
 
163
    % mkdir tutorial
 
164
    % cd tutorial
 
165
    % ls -a
 
166
    ./  ../
 
167
    % pwd
 
168
    /home/mbp/work/bzr.test/tutorial
 
169
    %
 
170
    % bzr init
 
171
    % ls -aF
 
172
    ./  ../  .bzr/
 
173
    %
 
174
 
 
175
As with CVS, there are three classes of file: unknown, ignored, and
 
176
versioned.  The **add** command makes a file versioned: that is, changes
 
177
to it will be recorded by the system::
 
178
 
 
179
    % echo 'hello world' > hello.txt
 
180
    % bzr status
 
181
    unknown:
 
182
      hello.txt
 
183
    % bzr unknowns
 
184
    hello.txt
 
185
    % bzr add hello.txt
 
186
    added hello.txt
 
187
    % bzr unknowns
 
188
 
 
189
 
 
190
If you add the wrong file, simply use **bzr remove** to make it
 
191
unversioned again.  This does not delete the working copy.
 
192
 
 
193
Branch locations
 
194
================
 
195
 
 
196
All history is stored in a branch, which is just an on-disk directory
 
197
containing control files.  By default there is no separate repository or
 
198
database as used in svn or svk. You can choose to create a repository if
 
199
you want to (see the **bzr init-repo** command). You may wish to do this
 
200
if you have very large branches, or many branches of a moderately sized
 
201
project.
 
202
 
 
203
You'll usually refer to branches on your computer's filesystem just by
 
204
giving the name of the directory containing the branch.  bzr also supports
 
205
accessing branches over http and sftp, for example::
 
206
 
 
207
    % bzr log http://bazaar-vcs.org/bzr/bzr.dev/
 
208
    % bzr log sftp://bazaar-vcs.org/bzr/bzr.dev/
 
209
 
 
210
By installing bzr plugins you can also access branches using the rsync
 
211
protocol.
 
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
 
503
are created. The filename of the common base is appended with ".BASE",
 
504
the filename of the file containing your changes is appended with
 
505
".THIS" and the filename with the changes from the other tree is
 
506
appended with ".OTHER".  Using a program such as kdiff3, you can now
 
507
comfortably merge them into one file.  In order to commit you have to
 
508
rename the merged file (".THIS") to the original file name.  To
 
509
complete the conflict resolution you must use the resolve command,
 
510
which will remove the ".OTHER" and ".BASE" files.  As long as there
 
511
exist files with .BASE, .THIS or .OTHER the commit command will
 
512
report an error.
 
513
 
 
514
::
 
515
 
 
516
  % kdiff3 file.BASE file.OTHER file.THIS
 
517
  % mv file.THIS file
 
518
  % bzr resolve file
 
519
 
 
520
[**TODO**: explain conflict markers within files]
 
521
 
 
522
 
 
523
Publishing your branch
 
524
======================
 
525
 
 
526
You don't need a special server to publish a bzr branch, just a normal web
 
527
server.  Just mirror the files to your server, including the .bzr
 
528
directory.  One can push a branch (or the changes for a branch) by one of
 
529
the following three methods:
 
530
 
 
531
* Rsync:   rsync -avrz LOCALBRANCH  servername.com/path/to/directory
 
532
 
 
533
  (or any other tool for publishing a directory to a web site.)
 
534
 
 
535
* bzr push sftp://servername.com/path/to/directory 
 
536
 
 
537
  (The destination directory must already exist unless the
 
538
  ``--create-prefix`` option is used.)
 
539
 
 
540
* The rspush plugin that comes with BzrTools
 
541
 
 
542
 
 
543
Moving changes between trees 
 
544
============================
 
545
 
 
546
It happens to the best of us: sometimes you'll make changes in the wrong
 
547
tree.  Maybe because you've accidentally started work in the wrong directory,
 
548
maybe because as you're working, the change turns out to be bigger than you
 
549
expected, so you start a new branch for it.
 
550
 
 
551
To move your changes from one tree to another, use
 
552
 
 
553
::
 
554
 
 
555
  % cd NEWDIR
 
556
  % bzr merge --uncommitted OLDDIR
 
557
 
 
558
This will apply all of the uncommitted changes you made in OLDDIR to NEWDIR.
 
559
It will not apply committed changes, even if they could be applied to NEWDIR
 
560
with a regular merge.  The changes will remain in OLDDIR, but you can use **bzr
 
561
revert OLDDIR** to remove them, once you're satisfied with NEWDIR.
 
562
 
 
563
NEWDIR does not have to be a copy of OLDDIR, but they should be related.
 
564
The more different they are, the greater the chance of conflicts.