creating checkouts, bound branches and standalone branches from an existing branch

[James Blackwell]

On Tue, Feb 14, 2006 at 03:01:43PM +0100, Denys Duchier wrote:
> jblack at merconline.com (James Blackwell) writes:
> 
> >> I would propose that:
> >> 
> >> 	bzr get --commit=remote       URL PATH
> >>         bzr get --commit=local,remote URL PATH
> >>         bzr get --commit=local        URL PATH
> >
> > I propose the following:
> > ------------------------
> >  bzr branch
> >  bzr branch [-c|--checkout]
> >  bzr branch [-u|--unbound]
> >  bzr branch [-b|--bound]
> >  bzr branch --lightly-bound
> 

> I think you missed the point of my proposal since you offer another one
> -- looking singularly like my earlier one for "create" btw :-) -- based
> again on terminology rather than on use case; and you are suggesting
> short options, a sin for which I have already been castigated :-)

Denys,

Heh. Do we both agree and disagree?  I think that I agree with your idea
in spirit and disagree only upon a couple minor details. The part of your
concept that I really like is having one meta-command that provides a
gateway to the three different types of behaviours that we'd like to
provide during commit. I don't care much for the specific terms you used
(get is OK by me, but --remote and --local strike me as a bit ambigious).

Aye. I did get carried away with the short options. I originally wanted to
use --quick, which was too long to be really quick, so added -q.. but -q
would mean quiet and not quick... and thus I fell into the pit of hell.

I used "branch" instead of "get" because thats what the local community is
more accustomed to. I could live happily with either. I would prefer "get"
over the long term since the meaning is clear and its slightly easier to
type.

Remote and local should be changed if we follow the rule that you state.
They're not use cases because they're not an example of use.  Those two
words could qualify as places, or as destinations, or as definitions or as
criteries, but not as use cases. Then again I do not want to see the tool
written as a set of use cases. I instead want to see the UI designed in a
way that is anticipated by the use cases we predict while minimizing
incompatibility with those that we didn't.



Everyone,

If somebody suggested basing the trio of commands on use case, then
they need to go back and reconsider the situation -- seriously. We have
three cases of determining which places for which commits are stored. We
have many, many potential uses. I have provided three sets of examples
(two metaphoric and one practical) on why this is a mistake. 

When I need to take something apart, I use a "screwdriver". Sometimes I
need a flathead and other times a phillips.  Other times, I need to pound
the crap out of something.  For this, I reach for a "hammer". If I can't
find a hammer, then I use the back end of a screw driver and pound with
it. My point here is the same tool can solve the multiple use cases*

When I have a "turn this thing until it comes out" problem I use the
"screwdriver". At least until I strip the screw. I then turn to a different 
tool named "pliers" to yank at it until it comes out. Once I've sheared
the bolt I then turn to a third tool -- my power drill.... I think you see
where that's going. The point here is that a use case is usually solved by
a variety of tools.

I have a final example. Take a look at any reasonable desktop system. You
will find lists of things categorized by the type of the tool (games,
office, programming, web and so forth) and subcategorized by what the tool
does (freecell solitaire,  meld, openoffice calc, firefox and so on). What
you won't find is menu items like "I am bored", "I want to examine diffs",
"I want to add lots of numbers" or "I want to read slashdot." Doing so
would be silly because there is practically an infinite number of use
cases for any well designed tool. My point here is that presenting options
by use case limits the flexibility of a tool.**

A tool is not the right place for exposing use cases. The capability of a
tool is better exposed by using a tool model than a use case model because
the tools model provides the ability to mix and match to produce results
that were not predicted.

The right place for use cases is design and documentation. Design is
obvious; it provides an indicators for what sorts of minimal functionality
are required. Documentation is highly scalable, easily updateable and
provides the opportunity to show a user how to solve a particular use case
by by applying the tools in a creative way.  If you're smart, you jot down
the process used to solve a use case. If you're nice, share it with
others. 

The key part of usability for a program is not whether you guessed the
eight most likely ways that a user will want to use the program. Instead,
the important part is keeping the tool highly discoverable, easily
predictable and intuitive.  The user can then solve not just the eight use
cases you planned for, but the other upteen million other cases that you
didn't.

* Yes, like all good points, there is an exception. Use cases for a piece
  of software are good tools for developing the tool itself.

** You can see how bad this gets off in the Microsoft world. Many programs,
   in an attempt to simplify the UI, dramatically cut back on their
   features by limiting the user to 5-8 choices of types of things they
   can do. 


> You and I keep often company on IRC, asking lifeless to clarify what
> this terminology is really supposed to mean; and that should be an
> indication that terminology is perhaps not the right way to approach the
> design of the UI.  At least, it should not be the only way: there should
> be an easier point of entry.


> Jam revised my proposal and suggested to rename --commit to --access which
> indeed is a better choice:
> 
> 	bzr get --access=remote       URL PATH
> 	bzr get --access=local,remote URL PATH
> 	bzr get --access=local        URL PATH
> 
> For _creating_ repos and branches, I haven't yet thought of a nice way to think
> about use cases in a uniform and intuitive fashion.  It would be nice to have
> something like:
> 
> 	bzr new ...	start a new project
>         bzr get ...	get a copy of an existing project
> 
> but I have not yet been able to flesh out the "bzr new" idea in a way that makes
> me happy.
> 
> Cheers,
> 
> --Denys
> 
> 

-- 
My home page:   <a href="http://jblack.linuxguru.net">James Blackwell</a>
Gnupg 06357400  F-print AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060214/9d3c9ee8/attachment.pgp