[rfc] bzr-colo into core

[Alexander Belchenko]

Jelmer Vernooij пишет:
> On Thu, 2011-03-24 at 16:47 +0200, Alexander Belchenko wrote:
>> Jelmer Vernooij пишет:
>>> bzr-colocated is really simple (roughly 200 lines of code vs 3000 in
>>> bzr-colo) as it relies on most of the infrastructure already being in
>>> bzrlib. It doesn't add any extra commands for dealing with colocated
>>> branches but relies on the existing ones. bzr-colo adds its own set of
>>> commands that known about colocated branches. 
>> Does bzr-colocated has an equivalent of colo-branches to list all 
>> available branches and highlight the active one?
> bzr-colocated just provides a format, it is supposed to integrate with
> the standard bzr commands.

Yes, but are there set of bzr commands to work with colocated branches?
Do you think we need it? `bzr branches` command is not in the core, it's 
provided by bzrtools plugin.

My point here that bzr-colocated relies on core functionality, but I 
don't see anywhere reflection of colocated branches in the UI. bzr-colo 
gives us `colo:` path alias to perform the required tasks. So I can use 
core bzr commands to work with colocated branches, e.g.

bzr switch -b colo:foo/bar/spam

What does bzr-colocated provide in this regard? How it's supposed to be 
supported? That'll be my first question to start using bzr-colocated.

Jelmer, please, understand my comments right. I don't try to say that 
bzr-colo is superior. I'm using it and know many of its limitations and 
weak points. But I'm not sure that comparing 2 plugins based on the size 
of the codebase is right. I'd love to see something better than bzr-colo 
in the core, but please take a closer look on actual bzr-colo behavior 
and how it reflected in the typical usage first.

>> The size of bzr-colo codebase is bigger because it provides many new 
>> commands and help. Even qbzr integration.
> Those commands don't use the normal Bazaar API though, they bypass it.
> The commands are very specific to bzr-colo, they don't work with hg or
> git colocated branches. I realize that was not the original intent of
> bzr-colo, which was to get something actually working rather than
> waiting for the infrastructure in bzrlib to mature. I'm also not saying
> these commands are not useful, but that doesn't mean we should merge
> them as is.

I never said we should merge bzr-colo "as is". Furthermore, I'm strictly 
against this. See my first reply on the starting mail.

Yes, bzr-colo has been developed without needs of bzr-git and bzr-hg in 
mind. As you said it's more pragmatic and I definitely like this.

>> So if I'd trim it down, I'd say there are only 3 must-have commands to 
>> work with bzr-colo with a minimum of comfort: colo-ify, colo-fixup and 
>> colo-branches, and support for `colo:` path aliases. That's the basis. 
>> How big it will be?
> In the case of bzr-colocated "bzr upgrade" is the equivalent of
> "colo-ify"; I imagine we could also do colo-ify on the fly when the user
> creates the first colocated branch. "bzr branches" can display all
> colocated branches. What does colo-fixup do?

Fixes absolute path in the branch reference, of course. The famous 
absolute path in branch reference of the light checkout problem.

bzr-colocated is much better here, that's true.

But, bzr-colo has the `colo:` alias, that bzr-colocated does not 
provided. For me it's very important, because other bzr UI has no 
knowledge of colocated branches right now.

>>> bzr-colo's approach is more pragmatic: it actually works with released
>>> versions of Bazaar and doesn't require users to run bzr.dev or convert
>>> their control directories to a format that is only usable by other users
>>> who also have the plugin installed. On the other hand, it is less well
>>> well integrated with the existing bzrlib API - you can't open a bzr-colo
>>> branch using the standard bzrlib API, you can't use the bzr-colo
>>> commands to access "colocated" branches in git or hg repositories and it
>>> adds quite a lot of new bzr subcommands that duplicate existing
>>> commands.
>> I'm not quite agree when you say that bzr-colo added a lot of bzr 
>> subcommands duplicating core behavior. I see there is only few of them: 
>>   colo-branch (to create a new branch), colo-checkout (to create a new 
>> checkout), colo-fetch (to setup the local copy of the project). Other 
>> commands either colo-specific or work as useful helpers.

> I think colo-branch ("branch"), colo-branches ("branches"),

note again: branches are not builtin command.

> colo-checkout ("checkout"), colo-pull ("pull"), colo-init ("init"),
> colo-prune ("rmbranch") don't have to be separate commands.

Does rmbranch is new command? What about cleaning shared repo after 
rmbranch? That should be bzr gc?

colo-pull is not just pull alias. Of course regular pull should be 
updated first to get the same behavior as colo-pull.

> The other commands also seem useful (and we certainly don't have
> anything like that in core at the moment), but I think we should discuss
> what we want the UI to be like rather than simply merging them.

Again, I don't think merging bzr-colo directly will help. That's not my 
point. I don't say that using bzr-colo commands is only one way to go.

bzr UI should be significantly updated. Again I tend to agree with 
fullermd here: there won't be standalone branches anymore, bzr always 
will create colo-thing. But I have no vision how it will be.

colocated branches with hidden shared repo in .bzr/branches are not very 
good: they don't use high level shared repository, so if you have

bzr-repo/   <-- shared repo
   bzr.dev  <-- repo branch
   bzr-2.1  <-- repo branch

and then one day converts both bzr.dev and bzr-2.1 into colo-thing you 
no more have the cheap update for all colo-thing-internal-repos when you 
do pull in the one branch. That's bad, and every colo-thing has their 
own repo and therefore wastes the space. That's bad.

-- 
All the dude wanted was his rug back