Some things about the bzr version control system.

---

Populate a branch with bzr checkout ..

Usual circumstance: I've been working on something on one computer and want to push it to another computer. bzr push remote sends it over there but doesn't populate the working tree. So next time I'm on the other computer, I need to do a bzr checkout . to get the actual files there.

Reorganising branches.

I mostly use VCS to keep things in step on several machines so I use the "one user, several machines" layout. In practice, that means having one central storage location and everything else is a checkout of something there. That works reasonably well, except that sometimes when I'm branching a project then I forget to make the branch first on the central location and then check it out to the current location. Rather, I sometimes just make a branch of the local checkout. (Sometimes I do this deliberately if I think that the branch isn't important, but then sometimes it grows into something important so this isn't a good excuse!) So from time to time, I need to reorganise the branches to get them all back in the central repository. There are two problems with just copying it over. Firstly, the central storage is a "no trees" area so blind copying results in files that wouldn't normally be there. Not a problem, but untidy. Secondly, and more importantly, I don't just want to copy the new branch to the central storage location, I want to ensure that it thinks it is a branch of the original one, not the checkout on the local machine.

This is where the bzr rebase plugin helps. Here's the minimal scenario:

~~~

Create a repository and an initial project

mkdir repo cd repo bzr init-repo --no-trees . bzr init a cd ..

Get a checkout of that project and do something

mkdir work cd work bzr checkout ../repo/a cd a touch A bzr add A bzr commit -m 'added A' cd ..

Branch the initial project and do some more

bzr branch a b cd b for f in B C D E; do touch $f bzr add $f bzr commit -m "added $f" done cd ..

Now work/b is a modified branch of work/a, which is a checkout of repo/a

cd ../repo branch a b cd ../work bzr checkout ../repo/b ab

repo/b is a branch of a and work/ab is a checkout of it

now we want to graft b onto ab

obviously, replay the 2 by the right revision: one after the top of repo/a

cd ab bzr replay --r 2.. ../b cd ..

at this point, work/b and work/ab are, in effect, the same

To make work/b a checkout of rep/b involves:

cd b bzr bind ../../rep/b cd ..

but this doesn't make it a clone of ab, unfortunately.

Best is now to delete work/b and work solely on work/ab

~~~

Actually, the above didn't work on a more complicated setup. After lots of trials and errors, I eventually found this bug report. The hack fixed the problems that I was having completely!