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?)
Quilt+svn is OK, but my personal preference is stgit+svn. :)
Anyway, enough of the opinion piece, I hope the bzr stuff helps somebody.
Andrew
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
