Better reviews for the same cost in gcc-linaro

Andrew Stubbs andrew.stubbs at
Tue Mar 15 10:53:57 UTC 2011

Richard may know all this, but I'm just going to post anyway in case 
some people reading can benefit from some tips.

I find that bzr is slow - there's no getting around it, but there are 
some tricks that can help.

On 14/03/11 11:12, Richard Sandiford wrote:
> My concern was that, again with my way of working, the process is:
>    1) develop fix
>    2) branch trunk (creating a whole new gcc source tree, so quite slow)

This is going to take a short while however you cut it, but doing it the 
naive way is *very* slow.

So, make sure you use "init-repo". This creates a top-level ".bzr" 
directory that can be shared between many branches. This cuts down on 
network usage, and speeds up local branching also.

To set it up:

    mkdir my_work_dir
    cd my_work_dir
    bzr init-repo .
    bzr branch lp:gcc-linaro my_1st_branch
    bzr branch lp:gcc-linaro my_2nd_branch

Basically, any branches you create within sub-directories of 
"my_work_dir" have shared history, so there's no need to waste time 
duplicating it.

I believe hard-linking should be a win too, but I don't use it much:

    bzr branch --hardlink my_1st_branch my_2nd_branch

You might also try experimenting with local stacked branches (so the new 
one has only shallow history), but I'm not sure there's any advantage if 
you use a shared repo:

    bzr branch --stacked my_1st_branch my_2nd_branch

>    3) apply fix to new branch, with ChangeLog entry
>    4) publish new branch in laucnhpad

I find "bzr push" is quite fast, but there's a special gotcha - it 
always stacks new feature branches on top of the gcc-linaro/4.5 branch 
(more accurately, the "focus of development" branch), and if you're 
working with 4.4 or 4.6, that means there quite a lot of difference to 

You can fix this by telling it what branch to stack on:

bzr push 

Unfortunately, the "lp:..." form doesn't work with --stacked-on. :(

>    5) wait for branch to be processed by launchpad (only a few minutes,
>       nothing major)
>    6) ask for a review
>    7) merge to trunk (with the inevitable ChangeLog merge failure
>       that you mentioned).
> whereas the upstream way would be:
>    1) develop fix
>    2) ask for a review, attaching patch
>    3) apply patch to trunk, with ChangeLog entry
> The upstream way feels much simpler, and avoids the merge failure hassle.

True. If you prefer, by all means include the ChangeLog entry in the 
merge request, and it can be inserted into ChangeLog.linaro at merge time.

It makes no real difference to me, but it does mean that if there is 
anybody out there pulling toolchains from feature branches, the 
ChangeLogs won't be helpful. I doubt that anybody does that???

>> Short story is that we have a better tool than svn, so feature
>> branches may make some use cases overall easier and more transparent.
> Well, as you say, the size of GCC and its history is pushing the limits
> of bzr a bit.  For bug-fixing and committing, I actually find quilt+svn
> to be a fair bit more productive than bzr, and that's even with Andrew
> doing the heavy work on merging.

I'd say that calling bzr a better tool than svn is pushing it a bit. It 
has some nice features, and it works better than svn for launchpad's 
purposes, but I'd still rather use SVN or, better still, git. If bzr 
wasn't such a dog to use (for large projects), it would be as good as 
SVN or GIT, but it would not be "better" - just different. (Svn was 
lacking a good merge tool, but I believe that's fixed now?)

Quilt+svn is OK, but my personal preference is stgit+svn. :)

Anyway, enough of the opinion piece, I hope the bzr stuff helps somebody.


More information about the linaro-dev mailing list