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

[Maritza Mendez]

This is a valuable discussion.  One of the first "issues" I have when
introducing new people to bzr is the different meaning of "checkout."  This
word has been heavily overloaded by many VCS, not only bzr.  This is
especially hard for people migrating from centralized systems in which
checkout typically means a "reserved checkout" which means holding a
server-side write-lock.

I really like that bzr is so simple:
*Everything happens on a branch.
A branch is an ordered sequence of changesets, starting from a parent.
A branch may be bound or unbound to its parent.
A branch has storage.
The storage of a branch may include ancestral history or only local history.
The storage of a branch may include a working tree or not.
*
It gets more complicated with shared repos, stacked branches and dependent
branches, but many users don't need to know this to get started with bzr.
But the command names tend to hide the true simplicity.

Example.  The checkout capability in bzr is absolutely essential of course.
But I spend a lot of time explaining how checkout in bzr is different from
checkout in central VCS.  So in this way I agree with Mr. Shuttleworth in
that making checkouts light by default makes them more like what people
expect -- dependent on access to the parent.  But this actually is not what
I want for my users!  They need "heavy" checkouts -- bound branches.  To me,
saying bound branch is more meaningful than checkout.  English is not my
first language.  To me checkout says I have taken something from the library
and no one can have it until I return it.  That's not exactly how central
VCS works but similar.  chekcout implies some kind of posession.  That's
what bzr checkout means, regardless of wheter it is heavy or light.

Maybe this is hard for me because of english.  ok.  We love bzr no matter
what the commands are!

-M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20090415/a4aafa30/attachment.htm