Re: bzr repository ready?

["Stephen J. Turnbull" <stephen@xemacs.org>]

Richard Stallman writes:

 >     That's correct.  There is a better way, however, which is to use
 >     a stacked branch.  Stacked branches
 > 
 > I don't think I have seen the term "stacked branch" before.  Is it a
 > different term for something that has been discussed recently,
 > or is it something substantively different?

IIRC, it's a different concept; stacked branches are relatively new.
They were developed for use on project hosts like Launchpad[1], where they
can save a huge amount of space for projects with many branches.
There are two dimensions to be considered here.

Terminological note: in this post, by "checkout" I mean a "lightweight
checkout directly from the upstream master branch".  A "committer" is
a "maintainer or other person allowed to send changes directly to the
upstream master branch".

The first is "does plain 'bzr commit' commit to a local repository, to
the parent (typically remote) repository, or to both?"  A normal
branch commits to the local repository, a checkout to the remote
repository, and a bound branch to both.  This means that a normal
branch diverges from its parent branch immediately, a checkout cannot
diverge, and a bound branch does not diverge unless the user takes
some exceptional action.  A *stacked branch*, like a (normal) branch,
commits to the local repository.

The second is "how much of the version history (file content) is
maintained locally?"  In a branch, full history of all versions that
are ancestor to any version in the branch is kept locally.  This is
also true of a bound branch.  In a checkout, no history at all is kept
locally.  A *stacked branch* is different from either: its history is
distributed between the local repository and the remote.  History
*before* the branch point is kept in the remote repository, while
*new* history is kept locally.  ("New history" definitely includes
merges from 3rd party branches and new commits, and IIRC also includes
updates from the parent branch).

A summary table is attached at the bottom.

Aside from small additional space savings, for committers the
advantage of a checkout over a stacked branch is that all of her
commits are immediately reflected in the upstream master, saving her
the effort of typing "bzr push".  The disadvantage is that all of her
commits are immediately reflected in the upstream master, costing her
the effort of managing the changes by hand while improving and testing
them, because she can't commit until the patch is "good".

For non-committer hackers, the checkout is an all-around loss compared
to the stacked branch.  They cannot commit at all in the checkout.  In
return for this handicap, they can save a small amount of space.

For non-hackers (ie, beta testers) the checkout saves a small amount
of space at no cost since there's no need to commit.  I still advocate
use of stacked branches here, in hope that someday soon they will
experience a sudden urge to commit.

\ local history
   \  content      Full        Truncated        None
commit \
target  +-------------------+---------------+------------+
        |        (normal)   |   stacked     |            |
Local   |         branch    |    branch     |            |
        +-------------------+---------------+------------+
Remote  |                   |               |  checkout  |
        +-------------------+---------------+------------+
Both    |         bound     |               |            |
        |         branch    |               |            |
        +-------------------+---------------+------------+

Footnotes: 
[1]  I write "Launchpad" because this refers specifically to
Launchpad's feature of giving each developer a personal shared
repository for her "sandbox" branches.  If the "sandbox" branches are
instead kept in the main shared repository, then there will be no
additional space savings from making them stacked branches.  I'm not
familiar with Savannah's architecture.