Bound branch implementation

[Aaron Bentley]

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

Robert Collins wrote:
> So heres the proposal, in a nutshell:
> Binding to a branch, and checking out from a branch, will require that
> the branch have no working tree.

If we followed this proposal, we'd have:
1. Checkouts (no branch data, working tree)
2. Archive branches (revision history, but no ancestry data, no working
tree)
3. Tree-less standalone branches (branch data, no working tree)
4. Standalone branches (branch data, working tree)

Also, it's fairly easy to imagine situations in which it would be
desirable to bind to a branch with a working tree.  And push already
needs to be able to push to branches that have working trees.  So why
does the criterion of 'no working tree' make sense as a prerequisite for
binding?

> In the immediate future, push will give
> an error when pushing to a branch that is marked as having a working
> tree (unless it can successfully construct one), in the medium term it
> could splat the diff down across the wire. Branches without a working
> tree will put their history in the root, not in root/.bzr. Branch.open
> will look for both 'branch-format' + 'no-working-tree' and
> '.bzr/branch-format' accordingly.

Wouldn't this make it illegal to have branches in an archive named:
branch-format, branch-lock, branch-name, inventory, inventory.weave,
parent, pending-merges, README, revision-history, revision-store,
stat-cache and weaves?

I think it's reasonable to keep all the branch control files in a subdir
named '.bzr' or '_bzr' and to make just '.bzr' or '_bzr' illegal.  Also,
it's nice to have the rule that any visible directory (except the
storage directory or _bzr directories) is part of the branch namespace.

> Archive branches are no longer special cased to have no working trees -
> its just a normal working-tree-less branch in that respect.

I think making archive branches less of a special case by introducing a
new kind of branch is, by itself, not worth the cost.

> Its easier to describe how checkouts + bound branches + standalone
> branches interact:
> 'There are two kinds of branches, standalone branches which have a
> working copy of the source code, and shared-branches which contain just
> the history, and you do a checkout or a 'bind' to get a working copy of
> the code.'

I don't see how that's easier to describe than "There are two kinds of
branches, archive branches and standalone branches.  You can do a
'checkout' or 'bind' with either kind, but you must do it with archive
branches, since they have no working tree."

Off the top of my head, if you really want to simplify the model, you
should get rid of standalone branches at the same time.  They can easily
be represented as a treeless branch + a checkout in the same place.

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

iD8DBQFDefLD0F+nu1YWqI0RAib2AJ4qoOWkpBs4MPvcBVw35+ZgCsSn3QCfQBC7
JPYTjlAdmS2/POF3wy/uW4M=
=YY76
-----END PGP SIGNATURE-----