On Tue, Mar 15, 2011 at 11:53 PM, Andrew Stubbs <andrew.stu...@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 > --stacked-on=bzr+ssh://bazaar.launchpad.net/~linaro-toolchain-dev/gcc-linaro/4.6 > lp:~<user>/gcc-linaro/<newbranch> > > 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: https://wiki.linaro.org/WorkingGroups/ToolChain/BzrTips 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: https://wiki.linaro.org/MichaelHope/Sandbox/BzrIssues with the performance numbers from earlier in the thread. -- Michael _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
