diff options
Diffstat (limited to 'doc/en/user-guide/reusing_a_checkout.txt')
-rw-r--r-- | doc/en/user-guide/reusing_a_checkout.txt | 86 |
1 files changed, 86 insertions, 0 deletions
diff --git a/doc/en/user-guide/reusing_a_checkout.txt b/doc/en/user-guide/reusing_a_checkout.txt new file mode 100644 index 0000000..f5d602b --- /dev/null +++ b/doc/en/user-guide/reusing_a_checkout.txt @@ -0,0 +1,86 @@ +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, both committed and uncommitted. You need +to decide whether to keep them or not by running either ``revert`` +or ``commit``. + +An alternative to the bind+update recipe is using the ``switch`` +command. This is basically the same as removing the existing +branch and running ``checkout`` again on the new location, except +that any uncommitted changes in your tree are merged in. + +Note: As ``switch`` can potentially throw away committed changes in +order to make a checkout an accurate cache of a different bound branch, +it will fail by design if there are changes which have been committed +locally but are not yet committed to the most recently bound branch. +To truly abandon these changes, use the ``--force`` option. + + +Switching a lightweight checkout +-------------------------------- + +With a lightweight checkout, there are no local commits and ``switch`` +effectively changes which branch the working tree is associated with. +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 PROJECT + cd PROJECT + bzr branch bzr+ssh://centralhost/srv/bzr/PROJECT/trunk + bzr checkout --lightweight trunk my-sandbox + cd my-sandbox + (hack away) + +Note that 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 bzr+ssh://centralhost/srv/bzr/PROJECT/PROJECT-1.0 ../PROJECT-1.0 + bzr switch ../PROJECT-1.0 + (fix bug in 1.0) + bzr commit -m "blah, blah blah" + bzr switch ../trunk + (go back to working on the trunk) + +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``). |