~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/en/user-guide/using_checkouts.txt

  • Committer: v.ladeuil+lp at free
  • Date: 2007-05-15 17:40:32 UTC
  • mto: (2485.8.44 bzr.connection.sharing)
  • mto: This revision was merged to the branch mainline in revision 2646.
  • Revision ID: v.ladeuil+lp@free.fr-20070515174032-qzdkangpv29l9e7g
Add a test that check that init connect only once. It fails.

* __init__.py:
(test_suite): Register the new test class.

* test_init.py: 
(InstrumentedTransport): A transport that can track connections.
(TransportHooks): Transport specific hooks.
(TestInit): Iniit command behavior tests.

* ftp.py:
(FtpTransport.__init__): Mark place that need fixing regarding
transport connection sharing

* builtins.py:
(cmd_init.run): Mark places that need fixing regarding transport
connection sharing.

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
Using checkouts
2
 
===============
3
 
 
4
 
Turning a branch into a checkout
5
 
--------------------------------
6
 
 
7
 
If you have a local branch and wish to make it a checkout, use the
8
 
``bind`` command like this::
9
 
 
10
 
  bzr bind bzr+ssh://centralhost/srv/bzr/PROJECT/trunk
11
 
 
12
 
This is necessary, for example, after creating a central branch using
13
 
``push`` as illustrated in the previous section.
14
 
 
15
 
After this, commits will be applied to the bound branch before
16
 
being applied locally.
17
 
 
18
 
Turning a checkout into a branch
19
 
--------------------------------
20
 
 
21
 
If you have a checkout and wish to make it a normal branch, use the
22
 
``unbind`` command like this::
23
 
 
24
 
  bzr unbind
25
 
 
26
 
After this, commits will only be applied locally.
27
 
 
28
 
Getting a checkout
29
 
------------------
30
 
 
31
 
When working in a team using a central branch, one person needs
32
 
to provide some initial content as shown in the previous section.
33
 
After that, each person should use the ``checkout`` command to
34
 
create their local checkout, i.e. the sandbox in which they
35
 
will make their changes.
36
 
 
37
 
Unlike Subversion and CVS, in Bazaar the ``checkout`` command creates a
38
 
local full copy of history in addition to creating a working tree holding
39
 
the latest content. This means that operations such as ``diff`` and ``log``
40
 
are fast and can still be used when disconnected from the central location.
41
 
 
42
 
Getting a lightweight checkout
43
 
------------------------------
44
 
 
45
 
While Bazaar does its best to efficiently store version history, there
46
 
are occasions when the history is simply not wanted. For example, if your
47
 
team is managing the content of a web site using Bazaar with a
48
 
central repository, then your release process might be as simple as
49
 
updating a checkout of the content on the public web server. In this
50
 
case, you probably don't want the history downloaded to that location
51
 
as doing so:
52
 
 
53
 
 * wastes disk space holding history that isn't needed there
54
 
 * exposes a Bazaar branch that you may want kept private.
55
 
 
56
 
To get a history-less checkout in Bazaar, use the ``--lightweight``
57
 
option like this::
58
 
 
59
 
  bzr checkout --lightweight bzr+ssh://centralhost/srv/bzr/PROJECT/trunk
60
 
 
61
 
Of course, many of the benefits of a normal checkout are lost by doing
62
 
this but that's a tradeoff you can make if and when it makes sense.
63
 
 
64
 
The ``--lightweight`` option only applies to checkouts, not to all branches.
65
 
 
66
 
Note: If your code base is really large and disk space on your computer
67
 
is limited, lightweight checkouts may be the right choice for you.
68
 
Be sure to consider all your options though including
69
 
`shared repositories <branching_a_project.html#a-reminder-about-shared-repositories>`_,
70
 
`stacked branches <stacked.html>`_, and
71
 
`reusing a checkout <reusing_a_checkout.html>`_.
72
 
 
73
 
Updating to the latest content
74
 
------------------------------
75
 
 
76
 
One of the important aspects of working in lockstep with others is
77
 
keeping your checkout up to date with the latest changes made to
78
 
the central branch. Just as you would in Subversion or CVS, you do
79
 
this in Bazaar by using the ``update`` command like this::
80
 
 
81
 
  bzr update
82
 
 
83
 
This gets any new revisions available in the bound branch and
84
 
merges your local changes, if any.
85
 
 
86
 
Handling commit failures
87
 
------------------------
88
 
 
89
 
Note that your checkout *must* be up to date with the bound branch
90
 
before running ``commit``. Bazaar is actually stricter about this
91
 
than Subversion or CVS - you need to be up to date with the full
92
 
tree, not just for the files you've changed. Bazaar will ask you
93
 
to run ``update`` if it detects that a revision has been added to
94
 
the central location since you last updated.
95
 
 
96
 
If the network connection to the bound branch is lost, the commit will
97
 
fail. Some alternative ways of working around that are outlined next.