Re: bzr repository ready?

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

Eli Zaretskii writes:

 > But the EmacsWiki page does use the "lightweight branch" terminology.
 > Should it be corrected?

Yes.

 > > A non lightweight checkout supports committing changes without sending
 > > them to the parent branch, using a command line option.
 > 
 > When and why would this be useful?

It's useful for splitting your history into bite-size, coherent pieces
that you aren't ready to push to the mainline.  For example, you might
add an argument to foofunc in foo.el, and fix all the calls in core
Lisp.  Now you commit.  Next you go through all the packages, and fix
them up too, with a separate commit to each one, because you're not as
sure you understand the code in each one.  This allows you to add a
comment explaining your uncertainty to the commit log, or have the
package's principal maintainer veto that commit only while everything
else goes through.

Then you cd to your local copy of the mainline branch, merge that
branch into it, and push to the public repo.  By default bzr log will
show only that the whole branch got merged, but someone who is curious
can see the detailed history.

 > > A lightweight checkout does not support this because it lacks the
 > > local VC data.
 > 
 > Would a lightweight checkout from the master repository be a good idea
 > for people who do not intend to send patches, just build the current
 > development version?

Yes.  I take back what I wrote in my previous response; this is indeed
an *excellent* third reason for lightweight checkouts, probably much
more important than "casual contribution".

 > > Actually, a non lightweight checkout is what Bazaar calls a bound
 > > branch. You can unbind a non-ligthweigth checkout anytimme for
 > > converting it to a regular branch and you can bind a branch to some
 > > other branch to convert it to a checkout of that branch.
 > 
 > So checkouts and branches are mostly the same?

No.  In principle, a checkout is not a branch at all.  It contains the
working tree, but no history, and by default only enough metadata to
tell bzr which repository to get history and other metadata from.
Since the parent repository may be on another host, "log", "diff", and
"commit" become expensive operations, and pull and push are no-ops.

On the other hand, a branch *is* a line of historical development.  It
is the history.  The working tree is optional (and some workflows use
shared repositories that contain only treeless branches).

A "bound branch" used to be called a "heavyweight checkout", the idea
being that most of the time you operate as a checkout but when
necessary (you're on the train, your ISP is taking a siesta), you have
a local cache of history.  That turned out to be a bad idea.  To the
extent that you actually use the local cache, it turns out to be a
quite different workflow from the (lightweight) checkout in practice.
Some people are still fans of bound branches, but it's a specialized
workflow.  The general trend is away from them.

The "heavyweight checkout" terminology is severely deprecated, and you
won't see it on bzr channels any more.