Better reviews for the same cost in gcc-linaro
michael.hope at linaro.org
Tue Mar 15 20:57:02 UTC 2011
On Tue, Mar 15, 2011 at 11:53 PM, Andrew Stubbs
<andrew.stubbs at linaro.org> wrote:
> 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 upload.
> 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?)
I prefer bzr over svn for this project for reasons that are better
discussed over a beer...
I've updated the BzrTips page on the wiki:
with links out to Andrew's, Loic's, and Martin's emails. If these
tips work for you, please edit the wiki.
I've also updated the BzrIssues page at:
with the performance numbers from earlier in the thread.
More information about the linaro-dev