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

[Jelmer Vernooij]

On Thu, Apr 16, 2009 at 12:40:51AM +1000, Ian Clatworthy wrote:
> With our shiny new repository format almost ready to go, we're
> fast approaching the time for calling something Bazaar 2.0.
> Think June/July as a likely line in the sand IIUIC.

> And high on the list of things many of us want to see as part of
> 2.0 is a gentler on-ramp for new users. While we have a deliberate
> policy of maintaining backwards compatibility 99% of the time,
> releasing 2.0 though is a rare opportunity for us to take a
> hard, objective look at our *overall* usability, making changes
> if they are warranted. It's fine to add feature after feature
> over time but does the net whole still make sense to new users?
> Recently, we've been hearing otherwise.

> Numerous ideas have been put forward recently to improve the
> new user on-ramp, e.g. my draft spec on easier workspace setup,
> Robert's email re implicit shared repo creation and the (poorly
> titled) email thread re hard-linking local repositories. This
> patch throws some more ideas into the mix, namely:

> 1. checkouts should be lightweight by default (ala svn)
I think this would be a very good idea; especially since checkouts
were originally named that way to be familiar to CVS/SVN users it
makes a lot of sense to have them be lightweight by default.

One of the things that needs attention before we can do this 
is the performance of lightweight checkouts when they're bound to remote 
branches. Right now, lightweight checkouts are even lighter than svn 
working copies and a lot of operations (not just commits) need communication
with the master branch since the base revision of the working tree is not
stored locally. 

Perhaps checkouts could be stacked on the master branch by default?
That way we at least have the base revision available for diff,
status, etc. That would also make it possible to use --local.

> 2. a branch could reuse the repository of a dependent branch
>    without needing to explicitly create a shared repo in a parent
>    directory.
This seems to share the same advantages and disadvantages of stacking
branches by default - less data to copy when cloning a branch, but the
chance to accidently remove history if you (re)move the branch on which
you're stacked. What is the difference?

Cheers,

Jelmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090415/e66c61cf/attachment.pgp