Help promoting Bazaar
Chris Hecker
checker at d6.com
Thu Jul 15 22:24:37 BST 2010
Thanks for this, it's a good description and should be on the wiki
somewhere.
If I have an initially unshared repository, like in your first example,
can I branch it into a shared repository later, so get the storage
benefits if I want to do a bunch of related branch work?
Thanks,
Chris
On 2010/07/15 05:17, Talden wrote:
>>>> 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
>
>
More information about the bazaar
mailing list