Feedback from evaluation in a corporate environment

[Ian Clatworthy]

Paul Moore wrote:
> 2010/1/8 Barry Warsaw <barry at canonical.com>:
>> On Jan 08, 2010, at 03:50 PM, Philippe Lhoste wrote:
>>
>>> I understand the irony (yes?) but I felt I should explain why a simple
>>> 'init' is still useful.
>> 'bzr init' is a useful command but it, and init-repo probably do not have the
>> best names to encourage people to use the right command at the right time.
> 
> While I was (to an extent) being ironic, it nevertheless remains true
> that the *normal* response when people note that they have performance
> issues and it becomes obvious that they used "bzr init" is to say "you
> shouldn't have done that".
> 
> So based on that I'd say that "bzr init" is not the right command if
> I'm going to hit performance issues. But how can I know that in
> advance?

It's a very good point.

> Barry's distinction between personal/new and established is a start,
> but is it correct or useful?

> Don't forget, this is a problem for new users, so "use your
> judgement" is not appropriate - by definition, new users have no
> judgement on these matters yet.

All agreed. We've certainly fallen into a classic UI problem here:
experienced users no longer feel the pain & frustration of a new user so
other itches get scratched in preference to making "ramp-up" as smooth
as it possibly could be.

On the positive side, I'd argue we've made *some* progress here in the
last 6 months. For example, the new website and better installers with
GUI tools and more plugins bundled have helped.

I've also made some initial steps inside Bazaar Explorer to simplify
things so that well-performing setups happen *by default*. For example:

1. The Initialize dialog is "model based" so that users say how they
   want to work (feature branches, shared tree, plain branch) and it
   builds the right layout on disk for you. The default model -
   feature branches - is an efficient one.

2. The branch dialog checks that the destination is inside a shared
   repository. If not, it suggests the user creates one and guides
   them through the process of doing so.

If we want to do similar things on the cli level, it's not hard
technically, just socially (i.e. getting agreement!). :-)

The Initialize dialog just wraps a hidden command - init-ala-explorer. I
could easily rename that to "init-workspace" [#] (say) and flick the
switch to make it non-hidden. Anyone with Explorer installed (that's
everyone right :-) ) could that use the more powerful command to init
things.

Making cli branch check for a shared repo at the destination is probably
trickier, given we explicitly avoid interactive commands as much as
possible. It might still be value to extend brakch with workspace model
options so you can say something like:

  bzr branch --shared-tree source destination

I don't have a simple answer here, though I will say that we want this
smarter branching for branches, bound branches and heavyweight
checkouts. We therefore need to do something intelligent in both branch
and checkout, unless (like Explorer) we "ditch" heavyweight checkouts
altogether and encourage users to use bound branches instead.

There's certainly plenty of room for further improvement in this area on
multiple levels: doc, cli and GUI. Explorer needs additional refinement
in Initialize and Branch to make these tasks both smoother and more
powerful (e.g. Al Budden's remote feature branches idea). In fact, with
the better working tree browser added on the weekend, that's now the
main blocker holding me back from calling it Explorer 1.0.

FWIW, *my* plan here is to (1) keep chipping away at making Explorer as
nice as possible in this area and *then* (2) worry about changing the
cli based on the lessons learned. Doing it the other way around will
only frustrate me unnecessarily I suspect.

Ian C.

[#] It may even be feasible to rename it to "init". To maintain
backwards compatibility, --plain-branch could be the default model
(though doing so would leave us with the very problem Paul is raising of
having badly performing defaults).