[RFC] Vanilla checkouts in 2.2

[Maritza Mendez]

+1 even if I am late.

As someone who has migrated two commercial teams to bzr in the last
year I can tell you checkouts are confusing for two reasons (1)
everyone thinks they know what "checkout" means from years of using
their current tool..(2) bzr uses the term very differently and richly.
 Because of 1 everyone looks up "checkout" in the manual and gets
confused because of 2.

Anything which avoids this confusion before it has a chance to start
is a very welcome step.

~M


On 1/11/10, Ian Clatworthy <ian.clatworthy at canonical.com> wrote:
> The recent thread re branch --bind has highlighted the fact that we
> don't have consensus on direction for checkouts. For the record, here's
> what I'd like to see us move towards in Bazaar 2.2.
>
> I'd like to see the distinction between heavyweight and lightweight
> checkouts go and we simply have checkouts. The --lightweight option
> should disappear. In it's place, I'd like to see a --history option that
> has one of the following values:
>
> * all - download all history
> * 0 - download no history
> * revspec - download just back to that revision
>
> So:
>
>   bzr checkout --history all == heavyweight (roughly speaking)
>   bzr checkout --history 0   == lightweight
>   bzr checkout --history -1  == download just the last revision
>
> I'm not currently fussed on what the default value for the history
> option should be. It may even vary depending on the source, e.g. 0 if
> local and -10 if remote.
>
> What I do care about more is consistent semantics: a command should
> apply to all checkouts or no checkouts at all. So unbind needs to be
> either always be legal or never be legal and, if legal, always mean
> exactly the same thing. (I guess that would depend on whether we felt
> "history" was managed in a bound branch or stacked branch or some new
> sort of branch.)
>
> I realise the above is a long way short of solving all the issues around
> our user model. OTOH, I think it would be a valuable increase in
> functionality (with arguably a decrease in conceptual complexity). And I
> think we can make this change without needing to solve other issues
> simultaneously.
>
> I'm also not volunteering to take on implementing the above: my time is
> pretty limited for numerous reasons. If the idea sounds interesting and
> there's some consensus it's worth trying, perhaps someone in the
> community could try prototyping it? We could then consider it for 2.2 if
> we liked it.
>
> Note: A change like this would need to get agreed to and landed by June
> say, leaving enough time for us to update the documentation and iron out
> any issues. That's one of the reasons I'm raising this now.
>
> Thoughts?
>
> Ian C.
>
> PS: Thanks to Matthew Fuller for his numerous documents on the Wiki:
> http://wiki.bazaar.canonical.com/MatthewFuller. Reading through those
> lately has crystallised my thoughts here.
>
>