Short, task-based bzr doclets for real-world use cases.

[Brian de Alwis]

On 15-Jan-2009, at 11:40 PM, Karl Fogel wrote:
>                ### (as an aside: why isn't this just "lp:bzr"?) ###


It works now!

	$ bzr branch lp:bzr
	Branched 3943 revision(s).
	$ cd bzr
	$ ./bzr --no-plugins version
	Bazaar (bzr) 1.12dev
	[...]

On 16-Jan-2009, at 3:56 AM, Paul Moore wrote:
> On 15-Jan-2009, at 11:40 PM, Karl Fogel wrote:
>> This turns out not to have been the best way to organize things :-).
>
> That in itself is an issue. In my view, the "natural" way for a new
> user to work (ie., the one he stumbles on without needing help from
> experts) should be correct (at least acceptable, if not optimal).

What makes something "natural" is highly dependent on your past, but  
that quibble aside, I claim that Karl's approach is fine for a simple  
one-off bug fix.  Having hacked and committed his change to his local  
branch from lp:bzr, he could have then done either of the following:

	$ bzr diff -r submit:		(takes about 5 seconds, wall time)
	$ bzr send				(takes about 12 seconds wall time)

This works as bzr uses the parent in the absence of an configured  
submit branch.  Now if Karl was planning on doing some more bzr  
hacking, then this might not have been the optimal way of using bzr as  
it generated more network traffic.  But it's correct, they are correct  
and acceptable.

I think we need to distinguish between (a) learning to use bzr and (b)  
learning to use bzr *well*.  Karl's tasklets would help in learning to  
use bzr well.

When I was looking into DVCS, I read a lot, and then started to play  
with Mercurial and bzr.  I too found that learning to use bzr well  
took time [1] -- but I don't think this was specific to bzr, but from  
wrapping my head around DVCSs.  Branches are expensive in centralized  
VCSs [2]; perhaps not in terms of making a branch, but certainly in  
managing merges to and from the branch.

[1] I gave up on Mercurial very quickly as I didn't like the CLI.  Bzr  
felt more "natural" :-)
[2] Subversion 1.5's merge info recording greatly simplifies merging.

On 16-Jan-2009, at 3:56 AM, Paul Moore wrote:
> (The hugely over-used example of needing a shared
> repo for performance, rather than a standalone branch, which is the
> "obvious" approach, is the canonical example here; your example above
> is another).

I think Paul makes a good point here -- we trivialize repositories by  
using them only for speed.  I think they're fantastic and should be  
treated by the documentation as first class objects.  I've been saved  
from having used a repository on three different occasions after  
mistakenly blowing away a branch too early (steps to recovery: 1. 'bzr  
heads --dead' and determine the right revid,  2.  'bzr init recovery- 
branch', and 3. 'bzr pull -r revid:... .' to recover the branch)


> While development is
> ongoing on improving speed, I get the impression that this isn't a use
> case that many people car about.

My one complaint about bzr is that it is slow.  It is improving though.

Brian.

-- 
"Amusement to an observing mind is study." - Benjamin Disraeli