← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

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

  • Committer: Alexander Belchenko
  • Date: 2006-07-30 16:43:12 UTC
  • mto: (1711.2.111 jam-integration)
  • mto: This revision was merged to the branch mainline in revision 1906.
  • Revision ID: bialix@ukr.net-20060730164312-b025fd3ff0cee59e
rename  gpl.txt => COPYING.txt

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/en/user-guide/reusing_a_checkout.txt
1
 
Reusing a checkout
2
 
==================
3
 
 
4
 
Motivation
5
 
----------
6
 
 
7
 
At times, it can be useful to have a single checkout as your
8
 
sandbox for working on multiple branches. Some possible reasons
9
 
for this include:
10
 
 
11
 
 * saving disk space when the working tree is large
12
 
 * developing in a fixed location.
13
 
 
14
 
In many cases, working tree disk usage swamps the size of the
15
 
``.bzr`` directory. If you want to work on multiple branches
16
 
but can't afford the overhead of a full working tree for each,
17
 
reusing a checkout across multiples branches is the way to go.
18
 
 
19
 
On other occasions, the location of your sandbox might be
20
 
configured into numerous development and testing tools. Once
21
 
again, reusing a checkout across multiple branches can help.
22
 
 
23
 
 
24
 
Changing where a branch is bound to
25
 
-----------------------------------
26
 
 
27
 
To change where a checkout is bound to, follow these steps:
28
 
 
29
 
 1. Make sure that any local changes have been committed
30
 
    centrally so that no work is lost.
31
 
 
32
 
 2. Use the ``bind`` command giving the URL of the new
33
 
    remote branch you wish to work on.
34
 
 
35
 
 3. Make your checkout a copy of the desired branch by using
36
 
    the ``update`` command followed by the ``revert`` command.
37
 
 
38
 
Note that simply binding to a new branch and running ``update``
39
 
merges in your local changes, both committed and uncommitted. You need
40
 
to decide whether to keep them or not by running either ``revert``
41
 
or ``commit``.
42
 
 
43
 
An alternative to the bind+update recipe is using the ``switch``
44
 
command. This is basically the same as removing the existing
45
 
branch and running ``checkout`` again on the new location, except
46
 
that any uncommitted changes in your tree are merged in.
47
 
 
48
 
Note: As ``switch`` can potentially throw away committed changes in
49
 
order to make a checkout an accurate cache of a different bound branch,
50
 
it will fail by design if there are changes which have been committed
51
 
locally but are not yet committed to the most recently bound branch.
52
 
To truly abandon these changes, use the ``--force`` option.
53
 
 
54
 
 
55
 
Switching a lightweight checkout
56
 
--------------------------------
57
 
 
58
 
With a lightweight checkout, there are no local commits and ``switch``
59
 
effectively changes which branch the working tree is associated with.
60
 
One possible setup is to use a lightweight checkout in combination
61
 
with a local tree-less repository. This lets you switch what you
62
 
are working on with ease. For example::
63
 
 
64
 
  bzr init-repo --no-trees PROJECT
65
 
  cd PROJECT
66
 
  bzr branch sftp://centralhost/srv/bzr/PROJECT/trunk
67
 
  bzr checkout --lightweight trunk my-sandbox
68
 
  cd my-sandbox
69
 
  (hack away)
70
 
 
71
 
Note that trunk in this example will have a ``.bzr`` directory within it
72
 
but there will be no working tree there as the branch was created in
73
 
a tree-less repository. You can grab or create as many branches as you
74
 
need there and switch between them as required. For example::
75
 
 
76
 
  (assuming in my-sandbox)
77
 
  bzr branch sftp://centralhost/srv/bzr/PROJECT/PROJECT-1.0 ../PROJECT-1.0
78
 
  bzr switch ../PROJECT-1.0
79
 
  (fix bug in 1.0)
80
 
  bzr commit -m "blah, blah blah"
81
 
  bzr switch ../trunk
82
 
  (go back to working on the trunk)
83
 
 
84
 
Note: The branches may be local only or they may be bound to
85
 
remote ones (by creating them with ``checkout`` or by using ``bind``
86
 
after creating them with ``branch``).