presenting the fundamental abstractions

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James Westby wrote:
> On (12/09/07 09:03), Andrew King wrote:
> Another issue that comes up here is "master" branches, i.e. checkouts.
> They don't change the nature of the object, and this may not be the
> place to explain them, but they are definitely a branch related thing.

I think you have the relationship of "master" and "bound" branches inverted.

When you have a heavyweight checkout "foo" whose branch is "bar":
 - "bar" contains the master branch
 - "foo" also has a branch-- its purpose is to cache the state of "bar".
    This branch is called a "bound" branch, because it is tied to foo.
    foo, on the other hand, doesn't even know about bar.


> This adds a revision to the repository consisting of the working tree's
> basis tree (the current head of the branch), with the files specified
> in the command line replaced by the working tree versions (default is
> all files to just take the revision tree). The branch is updated to
> point at the new revision, and the working tree's basis tree is changed
> to the tree that was created.
> 
> All of this is done on any master branch first.

Actually, it's mostly done on the local branch first, because the local
branch is presumed to be faster than the master branch.

> It shows the differences between the working tree and it's basis
> tree, which will be the head of the associated branch.

Usually, true, but not always.  If this is not the case, "bzr status"
will recommend running "bzr update".

> It should be able to I believe. This may well be a bug.

It is.  "bzr diff" also shares this bug.  Basically, our API doesn't
support treating branches the same way as working trees very well.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG6C7j0F+nu1YWqI0RAtt9AKCA0/blwrlgirzR/Sihr6+4ausqQQCfU0op
b59fJz48P7fRM2cVuwN32G0=
=Jghv
-----END PGP SIGNATURE-----