← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/tutorial.txt

  • Committer: Canonical.com Patch Queue Manager
  • Date: 2007-06-01 21:26:22 UTC
  • mfrom: (2499.2.1 jam-integration)
  • Revision ID: pqm@pqm.ubuntu.com-20070601212622-4hy742yfww9270dw
(Matthew Fuller) Updates to the tutorial

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/tutorial.txt
11
11
Bazaar Tutorial
12
12
===============
13
13
 
14
 
Current for bzr-0.8, 2006-04
 
14
Current for bzr-0.16, 2007-05
15
15
 
16
16
 
17
17
Introduction
180
180
    % bzr status
181
181
    unknown:
182
182
      hello.txt
183
 
    % bzr unknowns
184
 
    hello.txt
185
183
    % bzr add hello.txt
186
184
    added hello.txt
187
 
    % bzr unknowns
 
185
    % bzr status
 
186
    added:
 
187
      hello.txt
188
188
 
189
189
 
190
190
If you add the wrong file, simply use **bzr remove** to make it
191
 
unversioned again.  This does not delete the working copy.
 
191
unversioned again.  This does not delete the working copy in this case,
 
192
though it may in others [2]_.
 
193
 
 
194
.. [2] ``bzr remove`` will remove the working copy if it is currently
 
195
   versioned, but has no changes from the last committed version.  You
 
196
   can force the file to always be kept with the ``--keep`` option to
 
197
   ``bzr remove``, or force it to always be deleted with ``--force``.
192
198
 
193
199
Branch locations
194
200
================
210
216
By installing bzr plugins you can also access branches using the rsync
211
217
protocol.
212
218
 
 
219
See the `Publishing your branch`_ section for more about how to put your
 
220
branch at a given location.
 
221
 
213
222
Reviewing changes
214
223
=================
215
224
 
234
243
    modified:
235
244
       foo
236
245
 
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.
 
246
**bzr status** hides "boring" files that are either unchanged or ignored.
 
247
The status command can optionally be given the name of some files or
 
248
directories to check.
240
249
 
241
250
bzr diff
242
251
--------
246
255
''patch'', ''diffstat'', ''filterdiff'' and ''colordiff''::
247
256
 
248
257
    % bzr diff
249
 
    *** added file 'hello.txt'
250
 
    --- /dev/null 
251
 
    +++ hello.txt 
252
 
    @@ -1,0 +1,1 @@
 
258
    === added file 'hello.txt'
 
259
    --- hello.txt   1970-01-01 00:00:00 +0000
 
260
    +++ hello.txt   2005-10-18 14:23:29 +0000
 
261
    @@ -0,0 +1,1 @@
253
262
    +hello world
254
263
 
255
264
 
432
441
directory.  This is a bit different to CVS, which requires that you also
433
442
do **cvs remove**.
434
443
 
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. 
 
444
    **bzr remove** makes the file un-versioned, but may or may not delete
 
445
    the working copy [2]_.  This is useful when you add the wrong file,
 
446
    or decide that a file should actually not be versioned. 
438
447
 
439
448
::
440
449
 
457
466
=========
458
467
 
459
468
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*::
 
469
change to an existing project.  To do this, you'll need to get a copy of
 
470
the existing branch.  Because this new copy is potentially a new branch,
 
471
the command is called **branch**::
464
472
 
465
473
    % bzr branch http://bazaar-vcs.org/bzr/bzr.dev 
466
474
    % cd bzr.dev
469
477
operations on it locally: log, annotate, making and merging branches.
470
478
There will be an option to get only part of the history if you wish.
471
479
 
 
480
You can also get a copy of an existing branch by copying its directory,
 
481
expanding a tarball, or by a remote copy using something like rsync.
 
482
 
472
483
Following upstream changes
473
484
==========================
474
485
 
528
539
directory.  One can push a branch (or the changes for a branch) by one of
529
540
the following three methods:
530
541
 
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 
 
542
* The best method is to use bzr itself to do it.
 
543
 
 
544
  ::
 
545
 
 
546
    % bzr push sftp://servername.com/path/to/directory 
536
547
 
537
548
  (The destination directory must already exist unless the
538
549
  ``--create-prefix`` option is used.)
539
550
 
540
 
* The rspush plugin that comes with BzrTools
 
551
* Another option is the rspush plugin that comes with BzrTools, which
 
552
  uses rsync to push the changes to the revision history and the working
 
553
  tree.
541
554
 
 
555
You can also use copy the files around manually, by sending a tarball, or
 
556
using rsync, or other related file transfer methods.  This is usually
 
557
less safe than using ``push``, but may be faster or easier in some
 
558
situations.
542
559
 
543
560
Moving changes between trees 
544
561
============================