[MERGE/RFC] Userdoc Driven Design on the Bazaar 2.0 UI

[Christophe TROESTLER]

On Thu, 16 Apr 2009 08:59:17 -0500, John Arbash Meinel wrote:
> 
> Christophe TROESTLER wrote:
> > Let me ask a naive question: what is the difference between "bzr
> > checkout --lightweight; bzr unbind" and "bzr branch --stacked" ?
> > Users coming from other VCS certainly expect checkouts to depend on
> > the original branch.  [...]
> 
> You can't unbind a lightweight checkout.

Oh, I should have tried -- I did not really expect that.

What about the difference between "bzr checkout --lightweight $URL"
and "bzr branch --stacked; bzr bind $URL"?

> At that point, you have enough data for diff, and technically even
> enough data for offline commit. Though with something like this, I would
> tend to *not* allow you to unbind/commit --local. (Personally, I feel
> that commit --local adds more to confusion than benefit, perhaps because
> of how it interacts with 'update', and no short-form for pushing the
> local commits to remote.)

There may be technical reasons but, again from a naive user point of
view [1], this does not sound very nice.  Imagine a developer in a
university or company that works on a project X, using a checkout
(they were previously using SVN).  One day, on a plane, having a few
hours to kill, he decides to implement a few items on his todo list
for X.  But he cannot commit each of his fixes because he has a
checkout.  Too bad! (and too late, he should have foreseen this!). [2]

As for synchronizing the checkout with the master, maybe the easier
way is that commit --local triggers "unbind" (or there is no --local
and one requires that "unbind" is issued -- this could be suggested
when committing while not succeeding to reach the server) and have
"bind" take care of the needed work to reconcile the branches?  The
message bzr displays after a commit shoud make clear however that we
are committing locally in case we forget to bind when connected again!