[rfc] bzr-colo into core

Jelmer Vernooij jelmer at canonical.com
Thu Mar 24 15:23:57 UTC 2011


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.

> 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.

> 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?

> > 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"),
colo-checkout ("checkout"), colo-pull ("pull"), colo-init ("init"),
colo-prune ("rmbranch") don't have to be separate commands.

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.

Cheers,

Jelmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20110324/bd92214a/attachment-0001.pgp>


More information about the bazaar mailing list