[rfc] bzr-colo into core

[Martin Pool]

On 22 March 2011 00:02, Matthew D. Fuller <fullermd at over-yonder.net> wrote:
> On Mon, Mar 21, 2011 at 06:48:36PM +1100 I heard the voice of
> Martin Pool, and lo! it spake thus:
>>
>> I think this is the logical next step to make bzr's ui more powerful
>> and more friendly.
>
> +9 on the concept.
>
> I'm not so sanguine about the path of just bringing in the plugin more
> or less as-is though; this is a fairly big fundamental change, and I
> think it needs to be much more integrated, in terms of how we adjust
> the commands working, and how we shift our component modelling.

I agree.

> Yuo may remember that quite some time ago I wrote up a conceptual
> proposition at <http://wiki.bazaar.canonical.com/MatthewFuller/Fasces>
> for how pieces could come together for it, and I still feel fairly
> good about some of the attributes I posit as necessary; as a few
> examples:

I had read it, but then I forgot, so it was worth re-reading your document.

I agree we don't want to call the combined thing either a branch or a
repository.  I think 'fascis' will cause bialix to say 'what is a
fascis?' and if you say 'it means bundle' then he may very reasonably
ask 'so it's like a bundle then?'  But final names can come later.

It seems broadly to be going (or have gone) in the same direction as
bzr-colo, bzr-colocated, and this thread.  In particular it highlights
the idea of the importance of keeping checkouts, and of letting people
keep working in a one-directory and one working tree per-branch
fashion.

One interesting thing you suggest that bzr-colo does not normally do
(but can be forced to do) is to have a shared repository enclosing
several fasces.  Obviously that is easy to keep.

> - We don't make this some sort of branch, but rather a separate entity
>  containing branches (or even 'sticks' rather than branches, to
>  smoothly handle having checkouts as components).

I agree, but isn't that true in bzr-colo and -colocated too?

> - A much more fundamental shuffle to conceiving of branches by name
>  rather than location, as I maintain that trying to use shortcut
>  name-like things that get DWIM'd into locations is just a long-term
>  pain reservoir.  X-ref for instance Alexander's mail about the
>  problems with having paths to branches inside a colo.
>
> - Big shifts in command usage are going to be unpleasant.  Small
>  shifts are unavoidable at the least and good at best (e.g., the
>  reappropriation of 'clone'), but the primary command for pushing
>  stuff should stay 'push', etc (both for historical, and for "why is
>  this odd-seeming command name the allegedly 'normal' thing?"
>  reasons).

I agree with those two too.

> I believe that these sort of things can be done without simultaneously
> moving the earth out from under people who want to keep working in a
> classic-bzr fashion; that's one of the key items behind my fascis
> proposal.

Yes, I think we can get there too.  We need to have a clear picture of
where we're going to try to end up as the default case; so that that
is smooth but so that we do not needlessly cut out things people value
now.

So there are two main things I might try next: firstly putting up a
patch to deprecate excessive command aliases; secondly to write up a
science-fiction user guide for something near the centre of gravity of
this thread.

Martin