[rfc] bzr-colo into core

[Alexander Belchenko]

Alexander Belchenko пишет:
> Martin Pool пишет:
>> {summary}
>>
>> Let's make bzr-colo the default model for bzr 3.0 in September.
> 
> I'm going to provide more feedback based on my experience with bzr-colo, 

As promised, here is my feedback.

Some background. At work we're using Trac server as our project 
management tool, and trac-bzr for browsing the code. Bazaar model one 
directory per branch is very good fit svn-centric model of code browser 
in Trac. We have a really big project with many subcomponents, 
additional debug tools, docs branches, versioned binary products and 
even copy of some bzr plugins there. So there is very big amount of 
branches (754 as of today, about the half of them are inactive) grouped 
into many shared repositories (by components) all inside one Trac 
project. That's enough for us.

At the local machines we're usually works with shared repos and 
branches. Some time ago I've tried to use bound branches, but it created 
  too much hassles to run `bzr info` every time to decide whether I need 
pull or update. So I'm using only branches today.

I've tried to use model with local treeless branches and light checkout, 
but the setup always seems very complicated for me. Although it was very 
good to develop bzr plugins (qbzr and bzr-explorer). I used to have 
shared repo with development branches and light checkouts to my 
BZR_PLUGIN_PATH directory where I can develop my plugins and run them in 
the same time. That was and still is very important to develop and 
maintain several versions and releases of those plugins. But what I 
dislike in that setup is broken liaison between my branches and my 
trees. That's serious issue because I tend to carry my branches from one 
machine to another (from home to work and back) on the USB flash disk.

I've tried bzr-colocated one day, but it was not very usable, sorry.

When bzr-colo has been born by Neil that was great. It put everything 
into one working directory, so I can put all eggs into one basket and be 
happy. Almost.

I've been beaten by absolute branch reference several times, so at some 
point I've just gave up to use colocated for anything different than 
working on short-lived feature branches on local machines. That works 
good, so even when I need to move the colo workspace between machines I 
have to preserve the same absolute path to colo workspace, in my case I 
have the same working directory for development on all machines, like 
C:\work\xxx, e.g. C:\work\Bazaar\plugins for plugins etc. Actually it's 
not very difficult and it has some advantages, but sometimes I wish I 
can have more freedom here.

Looking at the bzr-colo commands set I can say the following.

The most important commands for me are:

bzr colo-ify -- so I always can switch to colo setup after cloning the 
branch

bzr colo-branches -- to list the branches inside colo repo and see where 
I am

bzr colo-fixup -- my the one help in the moving colo workspace around 
the disk. Because of absolute path limitations it's VERY important. (sigh)

Big thanks to Neil for the next 2 q-commands (qbzr integration ftw!), 
they're awesome:

bzr qprune (qdelete) -- to remove some branches

bzr qbranches -- to see branches in the GUI (I use it rarely though)

Also, bzr-colo provides `colo:` alias and Gary made really cool qlog, 
soI can see history of all branches in qlog simply by running
`bzr qlog colo:`. That's really awesome, please check it :-)

To create new branches I use `bzr switch -b xxx` often without colo: 
prefix, to merge feature branches into trunk I have to remember to use 
it, that's a pain:

bzr switch -b foo
hack hack hack commit commit commit
bzr switch trunk
bzr merge foo   # rats, it does not work
bzr merge colo:foo  # :-)

As I said I use colo workspace and colo branches for short lived feature 
branches. So commands to move/rename branches or cleaning repo from the 
old cruft are not important for me. For long lived things I'd better use 
plain branches inside shared repos.

I don't use colo-fetch and colo-pull for the same reason: colo 
workspaces are for short lived things, while this stuff is more 
appropriate for serious things, IMO.

I've tried to use colo-sync-to and colo-sync-from but I've gave up on 
them again because of the problem with absolute paths, and because 
they're not propagate deletions of branches. So today I just zip the 
entire working tree and copy it around as the opaque container.

Another thing that I see as bug but never bother to file a real bug: if 
I push from colo workspace to another local disk and push have to create 
a new branch it never creates a checkout for that branch. It seems push 
command operates on the treeless branch level, not on the light checkout 
level, and because the branch is treeless then push creates treeless 
copy. It's always wtf moment for me, but it does not happen too often to 
really create the itch.

At the beginning I told about our Trac server. I'm not sure how well 
colo workspaces will work on the server and how trac-bzr will support 
them. Really. And in fact I don't want colo on my server, because I have 
too much different components. I don't know how this problem is solved 
in trac-hg or trac-git, but I suspect their solutions assume you have 
only one project with many branches under your Trac control, not 
many-many-many components with many-many branches. The dude really only 
wants his old rug, not the new one.

So, reading replies to this thread I like the idea of Matthew Fuller the 
most (item 2 below):

1) it's not a 'colo repo', it's a 'colo thing'.  Considering it as a
    type of branch or repo messes everything up, and

2) you no longer create "standalone"[0] branches, you only create
    colo- thing's.  But a colo-thing with only one branch in it is
    functionally interchangeable with a current-day "standalone"
    branch.

Speaking in general I believe bzr ought to support colo model right and 
even recommend it for local development. Simply because 2 other big dvcs 
players out there do that by default and people used to this model.

I like git model more than hg model. As I understand it, in git you have 
origin/master as pristine mirror and just master for your development. 
The separation between remote branches and local branches can be very 
useful. Actually bzr-colo patially adapted this model.

The hg model of named branches seems very rigid and fragile, I saw many 
criticism on it. Anonymous heads idea is also contradicts to bzr branch 
model, I really do think names are important, but names should not be 
immutable.

HTH
-- 
All the dude wanted was his rug back