Help promoting Bazaar

[Talden]

>>> 2. Does "bzr branch Foo" do something similar to what it does in
>>> Mercurial and Git? i.e. make a new branch in the current repository,
>>> so you can switch between them with something like "bzr update" or
>>> "bzr checkout"?
>>
>> No. Bazaar by default uses the filesystem to distinguish branches; each
>> branch occupies a separate directory with its own working tree (if any).
>> The gack that a bunch of branches are subdirectories of a repository is
>> what causes them to be “in” that repository.
>
> I didn't understand your last sentence. I probably don't fully
> understand the Bazaar notion of repository vs branch. But I'm
> learning. I now know that Bazaar puts each branch in a separate
> directory.

The key to all of this is understanding three components in bazaars
view of revision control (someone shoot me if the terms aren't quite
correct but please use a small calibre round).

1. Repository - the thing that holds all of the commits (and how
they're related to one another)
2. A branch - a pointer to a specific commit in the directed graph of
commits (how they're related)
3. A working-tree - the files you have 'checked out' from a specific
branch (possibly with local changes and potentially out of date from
the current revision indicated by the branch they're checked out
from).

Bazaar lets you organise these things individually or together in
several initially confusing ways.

The simplest model... all in one folder - the commands below assume
there are no parent folders holding anything to do with bazaar (IE no
.bzr folders containing a repository anywhere further above the 'foo'
we're about to make)

CMD> cd .../dev
CMD> bzr init foo # Make a folder called 'foo' in a branch with a
working tree and repository.
CMD> cd foo
CMD> touch bar
CMD> bzr add
CMD> bzr commit -m "added bar"

.../dev/
  foo/
     .bzr/  <--- this contains your repository and because of our
simple choice also makes foo a branch and a working tree (checkout)
     bar


If we 'bzr branch .../dev/foo .../dev/foo2' we'll create another copy
of the history and working-tree - they're related but don't share any
storage (each of foo and foo2 are branches and repositories and
working trees)

.../dev/
  foo/
     .bzr/  <--- this contains your original repository and because of
our simple choice also makes foo a branch and a working tree
(checkout)
     bar
  foo2/
     .bzr/  <--- this contains another repository and because of our
simple choice also makes foo2 a branch and a working tree (checkout)
     bar


Better is to use a shared repository

(assume we're starting from scratch again)
CMD> cd .../dev
CMD> bzr init-repo repo
CMD> cd repo
CMD> bzr init foo
CMD> cd foo
CMD> touch bar
CMD> bzr add
CMD> bzr commit -m "added bar"

.../dev/
  repo/
    .bzr/   <--- this is a 'shared repository' for any branches under
it.  One copy of all of the commits of all branches under here
    foo/
       .bzr/  <--- this makes foo a branch and a working tree
(checkout) and uses the shared repository above in .../dev/repo
       bar


If we 'bzr branch .../dev/repo/foo .../dev/repo/foo2' we'd have one
copy of the history now and two branches with two working trees. EG

.../dev/
  repo/
    .bzr/   <--- this is a 'shared repository' for any branches under
it.  One copy of all of the commits of all branches under here
    foo/
       .bzr/  <--- this makes foo a branch and a working tree
(checkout) and uses the shared repository above in .../dev/repo
       bar
    foo2/
       .bzr/  <--- this makes foo2 a branch and a working tree
(checkout) and uses the shared repository above in .../dev/repo
       bar


But wait, what if I happen to have a project with a massive working
tree and I really only want to work with one branch at a time.  We can
separate working trees from branches.

CMD> cd .../dev
CMD> bzr init-repo --no-trees repo
CMD> cd repo
CMD> bzr init foo
CMD> bzr checkout foo work
CMD> cd work
CMD> touch bar
CMD> bzr add
CMD> bzr commit -m "added bar"

.../dev/
  repo/
    .bzr/   <--- this is a 'shared repository' for any branches under
it.  One copy of all of the commits of all branches under here
    foo/
       .bzr/  <--- this makes foo a branch that uses the shared
repository above in .../dev/repo
    work/
       .bzr/  <--- this makes work a working-tree (checkout) of branch
.../repo/foo
       bar

Now if we 'bzr branch .../dev/repo/foo .../dev/repo/foo2' we get
another branch but we still have only a single working-tree
(containing the content indicated by .../dev/repo/foo)

.../dev/
  repo/
    .bzr/   <--- this is a 'shared repository' for any branches under
it.  One copy of all of the commits of all branches under here
    foo/
       .bzr/  <--- this makes foo a branch that uses the shared
repository above in .../dev/repo
    foo2/
       .bzr/  <--- this makes foo2 a branch that uses the shared
repository above in .../dev/repo
    work/
       .bzr/  <--- this makes work a working-tree (checkout) of branch
.../repo/foo
       bar


We can 'switch' our working tree to showing the content for the
.../dev/repo/foo2 branch and make some changes

(assuming we're still in .../dev/repo/work here)
CMD> bzr switch .../dev/repo/foo2
CMD> touch baz
CMD> bzr add
CMD> bzr commit -m "added baz"

.../dev/
  repo/
    .bzr/   <--- this is a 'shared repository' for any branches under
it.  One copy of all of the commits of all branches under here
    foo/
       .bzr/  <--- this makes foo a branch that uses the shared
repository above in .../dev/repo
    foo2/
       .bzr/  <--- this makes foo2 a branch that uses the shared
repository above in .../dev/repo
    work/
       .bzr/  <--- this makes work a working-tree (checkout) of branch
.../repo/foo2
       bar
       baz

If we switch back to .../dev/repo/foo then 'baz' disappears because
it's not part of the content in that branch (unless we push our commit
there).

(assuming we're still in .../dev/repo/work here)
CMD> bzr switch .../dev/repo/foo

If a branch gets new revisions pushed to it (or pulled into it)
without updating a checkout that is pointing at that branch it gets
out of date - calling 'bzr update' in the checkout brings it up to
date.

All of this makes Bazaar very flexible at the expense of simplicity if
you try to understand it all at once (I've purposefully left out
merging, local commits, light-weight checkouts, bound branches, ...
some of which I think are really failed experiments in terms of
workflow)

Hopefully that makes sense and has been helpful.

--
Talden