← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/en/tutorials/tutorial.txt

  • Committer: Patrick Regan
  • Date: 2009-12-02 20:34:07 UTC
  • mto: (4852.3.3 2.1.0b4-doc-updates)
  • mto: This revision was merged to the branch mainline in revision 4856.
  • Revision ID: patrick.rubbs.regan@gmail.com-20091202203407-fjd0mshgn3j3foel
Removed trailing whitespace from files in doc directory

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/en/tutorials/tutorial.txt
2
2
.. into HTML or text.  In the future we plan to extract the example commands
3
3
.. and automatically test them.
4
4
 
5
 
.. This text was previously on the wiki at 
 
5
.. This text was previously on the wiki at
6
6
.. http://bazaar.canonical.com/IntroductionToBzr
7
7
.. but has been moved into the source tree so it can be kept in sync with
8
8
.. the source and possibly automatically checked.
20
20
on the other hand, you are familiar with revision control but not
21
21
decentralized revision control, then please start at "How DRCS is
22
22
different." Otherwise, get some coffee or tea, get comfortable and get
23
 
ready to catch up. 
 
23
ready to catch up.
24
24
 
25
25
The purpose of revision control
26
26
===============================
45
45
Revision control systems give users the ability to save changes to a
46
46
branch by "committing a **revision**". The revision created is essentially
47
47
a summary of the changes that were made since the last time the tree was
48
 
saved. 
 
48
saved.
49
49
 
50
50
These revisions have other uses as well. For example, one can comment
51
51
revisions to record what the recent set of changes meant by providing an
53
53
the web template to close the table" and "Added sftp suppport. Fixes #595"
54
54
        
55
55
We keep these logs so that if later there is some sort of problem with
56
 
sftp, we can figure out when the problem probably happened. 
 
56
sftp, we can figure out when the problem probably happened.
57
57
 
58
58
How DRCS is different
59
59
=====================
63
63
server and "checkout" the code. Doing so gives one a directory in which a
64
64
person can make changes and then commit. The RCS client then connects to
65
65
the RCS server and stores the changes. This method is known as the
66
 
centralized model. 
 
66
centralized model.
67
67
 
68
68
The centralized model can have some drawbacks. A centralized RCS requires
69
69
that one is able to connect to the server whenever one wants to do version
79
79
user only needs internet access when he wants to access the changes in
80
80
someone else's branch that are somewhere else.
81
81
 
82
 
 
 
82
 
83
83
A common requirement that many people have is the need to keep track of
84
84
the changes for a directory such as file and subdirectory changes.
85
85
Performing this tracking by hand is a awkward process that over time
86
86
becomes unwieldy. That is, until one considers version control tools such
87
87
as Bazaar. These tools automate the process of storing data by creating
88
 
a **revision** of the directory tree whenever the user asks. 
 
88
a **revision** of the directory tree whenever the user asks.
89
89
 
90
90
Revision control software such as Bazaar can do much more than just
91
91
storage and performing undo.  For example, with Bazaar a developer can
105
105
==============================
106
106
 
107
107
Bazaar installs a single new command, **bzr**.  Everything else is a
108
 
subcommand of this.  You can get some help with ``bzr help``. Some arguments 
 
108
subcommand of this.  You can get some help with ``bzr help``. Some arguments
109
109
are grouped in topics: ``bzr help topics`` to see which topics are available.
110
110
 
111
111
One function of a version control system is to keep track of who changed
147
147
 
148
148
.. [1] On Windows, the users configuration files can be found in the
149
149
   application data directory. So instead of ``~/.bazaar/branch.conf``
150
 
   the configuration file can be found as: 
 
150
   the configuration file can be found as:
151
151
   ``C:\Documents and Settings\<username>\Application Data\Bazaar\2.0\branch.conf``.
152
152
   The same is true for ``locations.conf``, ``ignore``, and the
153
153
   ``plugins`` directory.
230
230
its test suite before committing, to make sure that every revision is a
231
231
known-good state.  You can also review your changes, to make sure you're
232
232
committing what you intend to, and as a chance to rethink your work before
233
 
you permanently record it. 
 
233
you permanently record it.
234
234
 
235
 
Two bzr commands are particularly useful here: **status** and **diff**.  
 
235
Two bzr commands are particularly useful here: **status** and **diff**.
236
236
 
237
237
bzr status
238
238
----------
277
277
Some projects prefer patches to show a prefix at the start of the path
278
278
for old and new files.  The ``--prefix`` option can be used to provide
279
279
such a prefix.
280
 
As a shortcut, ``bzr diff -p1`` produces a form that works with the 
 
280
As a shortcut, ``bzr diff -p1`` produces a form that works with the
281
281
command ``patch -p1``.
282
282
 
283
283
 
285
285
==================
286
286
 
287
287
When the working tree state is satisfactory, it can be **committed** to
288
 
the branch, creating a new revision holding a snapshot of that state.  
 
288
the branch, creating a new revision holding a snapshot of that state.
289
289
 
290
290
bzr commit
291
291
----------
406
406
bzr ignore
407
407
----------
408
408
 
409
 
As an alternative to editing the ``.bzrignore`` file, you can use the 
 
409
As an alternative to editing the ``.bzrignore`` file, you can use the
410
410
``bzr ignore`` command. The ``bzr ignore`` command takes filenames and/or
411
411
patterns as arguments and then adds them to the ``.bzrignore`` file. If a
412
 
``.bzrignore`` file does not exist the ``bzr ignore`` command will 
 
412
``.bzrignore`` file does not exist the ``bzr ignore`` command will
413
413
automatically create one for you, and implicitly add it to be versioned::
414
414
 
415
415
    % bzr ignore tags
455
455
=================
456
456
 
457
457
The ``bzr info`` command shows some summary information about the working
458
 
tree and the branch history.  
 
458
tree and the branch history.
459
459
 
460
460
 
461
461
Versioning directories
484
484
 
485
485
``bzr remove`` makes the file un-versioned, but may or may not delete the
486
486
working copy [2]_.  This is useful when you add the wrong file, or decide that
487
 
a file should actually not be versioned. 
 
487
a file should actually not be versioned.
488
488
 
489
489
::
490
490
 
511
511
the existing branch.  Because this new copy is potentially a new branch,
512
512
the command is called **branch**::
513
513
 
514
 
    % bzr branch http://bazaar-vcs.org/bzr/bzr.dev 
 
514
    % bzr branch http://bazaar-vcs.org/bzr/bzr.dev
515
515
    % cd bzr.dev
516
516
 
517
517
This copies down the complete history of this branch, so we can do all
530
530
    % bzr pull
531
531
 
532
532
After this change, the local directory will be a mirror of the source. This
533
 
includes the ''revision-history'' - which is a list of the commits done in 
 
533
includes the ''revision-history'' - which is a list of the commits done in
534
534
this branch, rather than merged from other branches.
535
535
 
536
536
This command only works if your local (destination) branch is either an
584
584
 
585
585
  ::
586
586
 
587
 
    % bzr push sftp://servername.com/path/to/directory 
 
587
    % bzr push sftp://servername.com/path/to/directory
588
588
 
589
589
  (The destination directory must already exist unless the
590
590
  ``--create-prefix`` option is used.)
598
598
  than using ``push``, but may be faster or easier in some situations.
599
599
 
600
600
 
601
 
Moving changes between trees 
 
601
Moving changes between trees
602
602
============================
603
603
 
604
604
It happens to the best of us: sometimes you'll make changes in the wrong