~bzr-pqm/bzr/bzr.dev

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
Reusing a checkout
==================

Motivation
----------

At times, it can be useful to have a single checkout as your
sandbox for working on multiple branches. Some possible reasons
for this include:

 * saving disk space when the working tree is large
 * developing in a fixed location.

In many cases, working tree disk usage swamps the size of the
``.bzr`` directory. If you want to work on multiple branches
but can't afford the overhead of a full working tree for each,
reusing a checkout across multiples branches is the way to go.

On other occasions, the location of your sandbox might be
configured into numerous development and testing tools. Once
again, reusing a checkout across multiple branches can help.

Changing where a branch is bound to
-----------------------------------

To change where a checkout is bound to, follow these steps:

 1. Make sure that any local changes have been committed
    centrally so that no work is lost.

 2. Use the ``bind`` command giving the URL of the new
    remote branch you wish to work on.

 3. Make your checkout a copy of the desired branch by using
    the ``update`` command followed by the ``revert`` command.

Note that simply binding to a new branch
and running ``update`` merges in your local changes. You need
to decide whether to keep them or not by running either ``revert``
or ``commit``.

An alternative to the bind+update recipe is:

 1. Use the ``unbind`` command to turn the checkout into a normal branch.

 2. Run ``bzr pull --overwrite URL`` to make the branch a mirror of
    a new URL.

 3. Run ``bzr bind URL`` to bind to that URL.

Switching a lightweight checkout
--------------------------------

If you have a lightweight checkout, there is no local history
to worry about. In this case, you
can simply alter the branch that the checkout (i.e.
working tree) is referring to by using the ``switch`` command.

One possible setup is to use a lightweight checkout in combination
with a local tree-less repository. This lets you switch what you
are working on with ease. For example::

  bzr init-repo --no-trees X-repo
  cd X-repo
  bzr branch sftp://centralhost/srv/bzr/X-repo/X-trunk
  bzr checkout --lightweight X-trunk my-sandbox
  cd my-sandbox
  (hack away)

Note that X-trunk in this example will have a ``.bzr`` directory within it
but there will be no working tree there as the branch was created in
a tree-less repository. You can grab or create as many branches as you
need there and switch between them as required. For example::

  (assuming in my-sandbox)
  bzr branch sftp://centralhost/srv/bzr/X-repo/X-1.0 ../X-1.0
  bzr switch ../X-1.0
  (fix bug in 1.0)
  bzr commit -m "blah, blah blah"
  bzr switch ../X-trunk
  (go back to working on the trunk)

In many ways, ``switch`` operates like ``update`` in that it
refreshes your working tree and merges in any local changes you
have made. The primary different is that ``switch`` requires
a branch location and it is only supported (currently) on
lightweight checkouts. ``switch`` also only preserves
uncommitted changes while update keeps committed ones.

Note: The branches may be local only or they may be bound to
remote ones (by creating them with ``checkout`` or by using ``bind``
after creating them with ``branch``). ``switch`` and ``bind`` are
similar but different: switch controls which branch the working tree
refers to while ``bind`` associates a remote branch to the local one.