tortoisebzr-developers team mailing list archive

["Mark Hammond" <mhammond@xxxxxxxxxxxxxxxx>]

Quoting John, who is quoting me and Alex:

> >>>  Maybe there should be a generic "Update" item that "does
> >>> the right thing"?
> > ...
> 
> As always, the main problem is defining what the "right thing" is.

Yes - but maybe that "right thing" can be expressed by the dialog that appears.  In other words, its much easier to express complex concepts in a dialog box than with items on a menu.
 
[Note I'm not advocating anything yet - this is all just brainstorming]

> I would be hesitant to make TBZR too minimal, at the expense of not
> actually allowing people to work the way they want to. TBZR is likely 
> to become *the* face of bzr on windows. And it would be good to play 
> to our strengths.

Agreed 100% - we need to make bzr work intuitively for the "non-developer who used to be asked to use svn but is now asked to use bzr, but really couldn't care less", but also make sure we cover Bazaar's strenghths, and put a friendly face on the advanced features.

> I'm including the bzr mailing list, because I think this is a 
> big enough deal to warrant lots of people looking at it.

I adjusted the subject line accordingly :)

> The best way I can think of, is to define specific models of workflow.
> And either allow TBZR to be set up explicitly in each model, or to 
> have it configurable per project, or have them as separate menu entries, 
> etc.
> 
> To give some examples:
> 
> 1) Windows developer with minimal VCS experience, in an office, working
> in a
> shared environment with high-speed access to the central server. I
> would have two recommendations here:

While I agree we need to support those workflows you mention, I think we need to "lower" the bar here even more than that:

* As I implied above, we also need to handle the non-developer with almost zero VCS experience, who only uses source-control because the developers in the company beat him up if he doesn't.

* Whatever our workflow recommendations, many users will have that decision made for them.  ie, the developers in the organization will be telling that non-developer exactly what workflow to use.

<snip lots of good workflow scenarios>

> Anyway, I'm mostly just trying to define *why* bzr is flexible, and
> help generate ideas of how we can allow that flexibility without
> overwhelming the user.

While we must allow that flexibility, its not clear how much tortoise should be involved in *advocating* particular models.  Some of the workflows you describe require a fairly deep understanding of bzr's mental model.  Is it Tortoise's job to *lead* them to a particular workflow (and therefore requiring us to educate the user about these concepts on the way), or is it Tortoise's job to simply *support* those workflows once the user has obtained enough knowledge to conclude he would like to use Bazaar in these ways?
 
I'm leaning towards the former: someone moving from another VCS probably isn't interested in learning the ins-and-outs just yet - all they want to do is check their code in, and update to what their teammates have been doing - particularly when they were not the actual decision-maker in the choice of bzr - they are really only using bazaar because their project is.

It is along this line I mentioned a mythical "Update command that does the right thing."  [again, I point out this is just brainstorming :-].

* User right-clicks on a folder and selects "Magic Update" from the menu (OK, it probably will not say that)

* If the directory is a checkout, a dialog that looks something like this appears:

    +-------------------------------------------------+
    |  Update a bazaar checkout                       | 
    +-------------------------------------------------+
    | This directory is a checkout of foo-bar.        |
    |                                                 |
    | [Optionally explain what a checkout is]         |
    |                                                 |
    | To get the lastest changes in a checkout, you   |
    | generally perform an update operation           |
    |   (x) Update this checkout.                     |
    |                                                 |
    | Alternatively, you may like to update the c/o   |
    | to reference another branch.  etc etc.          |
    |   ( ) Pull a different branch                   |
    +-------------------------------------------------+

   with the usual case still being just an "OK" click/enter press away.

* If the directory is a branch, a dialog that looks something like this appears:

   [picture the above dialog, but with a focus on pulling a branch, but also options for merging if it detects tip divergance, for example]

I hope you get the idea - that we might be able to reduce complexity/confusion on the menus by transferring that complexity to some well-designed dialog boxes triggered by more generic terms on the menus.  Obviously, an 'Advanced' menu could still exist (and we could even include user-preferences about whether the advanced items appear on the top-level menu, for example)
 
Does that make sense, or have any appeal?

Thanks,

Mark