We currently use a feature branch / merge request / merge / test / push approach in gcc-linaro. This works fine for a reasonable cost but can mean that patches sit unreviewed and unmerged for up to a month. Ramana, Andrew, and I had a talk about this earlier in the week and I've written up the ideas here: https://wiki.linaro.org/MichaelHope/Sandbox/ReviewThoughts
We're a bit unique as gcc-linaro started from a mature base, running the testsuite takes days, and the product is so big that bzr takes a long time to work on it.
If you have experience in running a master branch or ideas on continious integration please have a read.
-- Michael
On Wed, Mar 9, 2011 at 2:56 PM, Michael Hope michael.hope@linaro.org wrote:
We currently use a feature branch / merge request / merge / test / push approach in gcc-linaro. This works fine for a reasonable cost but can mean that patches sit unreviewed and unmerged for up to a month. Ramana, Andrew, and I had a talk about this earlier in the week and I've written up the ideas here: https://wiki.linaro.org/MichaelHope/Sandbox/ReviewThoughts
We're a bit unique as gcc-linaro started from a mature base, running the testsuite takes days, and the product is so big that bzr takes a long time to work on it.
Hey Michael,
which target's are you actively building/testing fo (c,c++, etc?)
for reference, i'm just doing "c,c++", here's my average's..
xM: build: 14 hours, testsuite: 22 hours.. Panda: build: 9.5 hours, testsuite: 12hours..
Regards,
Hi Robert. The builds end up at: http://builds.linaro.org/toolchain/
and include the times for each step such as: http://builds.linaro.org/toolchain/gcc-linaro-4.5+bzr99475/logs/armv7l-maver... http://builds.linaro.org/toolchain/gcc-linaro-4.5+bzr99475/logs/armv7l-maver...
The carina machines are OMAP3s. I'm building C, C++, Fortran, Obj-C, and Obj-C++ and it takes 12 hours for the build and 16 for the testsuite.
These are on a NFS root. A ursa machine (PandaBoard) takes 5:14 to build at -j2 and 9 hours on the testsuite at -j1. 12 divided by 5.25 hours makes the Panda 2.3 x faster than the OMAP3.
-- Michael
On Thu, Mar 10, 2011 at 10:09 AM, Robert Nelson robertcnelson@gmail.com wrote:
On Wed, Mar 9, 2011 at 2:56 PM, Michael Hope michael.hope@linaro.org wrote:
We currently use a feature branch / merge request / merge / test / push approach in gcc-linaro. This works fine for a reasonable cost but can mean that patches sit unreviewed and unmerged for up to a month. Ramana, Andrew, and I had a talk about this earlier in the week and I've written up the ideas here: https://wiki.linaro.org/MichaelHope/Sandbox/ReviewThoughts
We're a bit unique as gcc-linaro started from a mature base, running the testsuite takes days, and the product is so big that bzr takes a long time to work on it.
Hey Michael,
which target's are you actively building/testing fo (c,c++, etc?)
for reference, i'm just doing "c,c++", here's my average's..
xM: build: 14 hours, testsuite: 22 hours.. Panda: build: 9.5 hours, testsuite: 12hours..
Regards,
-- Robert Nelson http://www.rcn-ee.com/
On Thu, 10 Mar 2011 09:56:27 +1300, Michael Hope michael.hope@linaro.org wrote:
We currently use a feature branch / merge request / merge / test / push approach in gcc-linaro. This works fine for a reasonable cost but can mean that patches sit unreviewed and unmerged for up to a month. Ramana, Andrew, and I had a talk about this earlier in the week and I've written up the ideas here: https://wiki.linaro.org/MichaelHope/Sandbox/ReviewThoughts
Hi Michael,
One thing that isn't clear to me from that page is why patches can go unreviewed for days. Do you tie the review to the testing somehow?
The proposal to have a designated person who will review patches promptly is one that has seen success in other projects. It trades off prompt reviews for more interuptions in someone's time, but it seems like that is often worth doing.
Some further questions:
* How frequently do problems get through review that are found by the test suite? * How frequently do problems get past the testsuite? * Would you be confident in your ability to have quality releases if there wasn't a testsuite run of each change before it lands in trunk?
Thanks,
James
On Thu, Mar 10, 2011 at 10:28 AM, James Westby james.westby@canonical.com wrote:
On Thu, 10 Mar 2011 09:56:27 +1300, Michael Hope michael.hope@linaro.org wrote:
We currently use a feature branch / merge request / merge / test / push approach in gcc-linaro. This works fine for a reasonable cost but can mean that patches sit unreviewed and unmerged for up to a month. Ramana, Andrew, and I had a talk about this earlier in the week and I've written up the ideas here: https://wiki.linaro.org/MichaelHope/Sandbox/ReviewThoughts
Hi Michael,
One thing that isn't clear to me from that page is why patches can go unreviewed for days. Do you tie the review to the testing somehow?
It's the way things are. Andrew has been doing all of the review and doing it as part of the integration phase. This will change.
The proposal to have a designated person who will review patches promptly is one that has seen success in other projects. It trades off prompt reviews for more interuptions in someone's time, but it seems like that is often worth doing.
Some further questions:
* How frequently do problems get through review that are found by the test suite?
Ideally the test suite should have been run before the review and have shown no regressions. That's how upstream does it. GCC is complicated so a review will miss subtle things.
* How frequently do problems get past the testsuite?
Being pessamistic, say every second patch causes a failure found in the field not found in the testsuite.
* Would you be confident in your ability to have quality releases if there wasn't a testsuite run of each change before it lands in trunk?
Not a quality release, no, but I have good confidence in the patches in general. It's unlikely that a commit would break trunk.
-- Michael
On Thu, 10 Mar 2011 11:09:21 +1300, Michael Hope michael.hope@linaro.org wrote:
* How frequently do problems get through review that are found by the test suite?
Ideally the test suite should have been run before the review and have shown no regressions. That's how upstream does it. GCC is complicated so a review will miss subtle things.
Sure, but reviews shouldn't be trying to catch every single problem that may exist.
If you don't have an idea of how much benefit test-before-merge has over just review-before-merge then it's going to be hard to estimate the risk of changing that scheme.
* How frequently do problems get past the testsuite?
Being pessamistic, say every second patch causes a failure found in the field not found in the testsuite.
That indicates that getting the code out there for (non-production) use would actually be worthwhile, rather than trying too hard to ensure everything goes through the testsuite. (Unless every patch has 10 problems that are not found in review but found by the testsuite.)
* Would you be confident in your ability to have quality releases if there wasn't a testsuite run of each change before it lands in trunk?
Not a quality release, no, but I have good confidence in the patches in general. It's unlikely that a commit would break trunk.
What sense are you using "break" here?
It sounds like prompt review->integration branch->beta testers | `->test suite->trunk
would be best if you don't think that you can have a quality release if you merge-before-test.
If you feel that you are equipped to recover from problems found by running the test suite against trunk before doing a release then it may be better to avoid the overhead and merge to trunk after prompt review, and deal with test failures when they happen.
Thanks,
James
On Thu, Mar 10, 2011 at 11:36 AM, James Westby james.westby@canonical.com wrote:
On Thu, 10 Mar 2011 11:09:21 +1300, Michael Hope michael.hope@linaro.org wrote:
* How frequently do problems get through review that are found by the test suite?
Ideally the test suite should have been run before the review and have shown no regressions. That's how upstream does it. GCC is complicated so a review will miss subtle things.
Sure, but reviews shouldn't be trying to catch every single problem that may exist.
If you don't have an idea of how much benefit test-before-merge has over just review-before-merge then it's going to be hard to estimate the risk of changing that scheme.
We currently have review+build+test before merge. If we checkin directly to trunk then it would be review+merge, then build+test automatically afterwards.
* How frequently do problems get past the testsuite?
Being pessamistic, say every second patch causes a failure found in the field not found in the testsuite.
That indicates that getting the code out there for (non-production) use would actually be worthwhile, rather than trying too hard to ensure everything goes through the testsuite. (Unless every patch has 10 problems that are not found in review but found by the testsuite.)
Yip. It's quite stable and bugs are quite rare. A huge testsuite like Ubuntu is a good way of exercising the compiler.
* Would you be confident in your ability to have quality releases if there wasn't a testsuite run of each change before it lands in trunk?
Not a quality release, no, but I have good confidence in the patches in general. It's unlikely that a commit would break trunk.
What sense are you using "break" here?
On second reading, too loosely. I meant 'fail to build', but most developers will want to run the testsuite. If the checkin before them caused a testsuite regression then they may get confused.
A timely automatic build would help with that: perhaps notify the previous author of the regression, and give the developer somewhere to easily check the state of their baseline.
It sounds like prompt review->integration branch->beta testers | `->test suite->trunk
would be best if you don't think that you can have a quality release if you merge-before-test.
Yip. The integration branch however may be Ubuntu itself. Matthias is fairly happy cherry-picking things so if these checkins/feature branches are at least reviewed and preferably build+tested then he can be the path to beta testers.
This may change when Linaro gets set up to build main.
If you feel that you are equipped to recover from problems found by running the test suite against trunk before doing a release then it may be better to avoid the overhead and merge to trunk after prompt review, and deal with test failures when they happen.
Agreed. The build+testsuite can happen automatically and probably within two days.
-- Michae
On 9 March 2011 20:56, Michael Hope michael.hope@linaro.org wrote:
We currently use a feature branch / merge request / merge / test / push approach in gcc-linaro. This works fine for a reasonable cost but can mean that patches sit unreviewed and unmerged for up to a month. Ramana, Andrew, and I had a talk about this earlier in the week and I've written up the ideas here: https://wiki.linaro.org/MichaelHope/Sandbox/ReviewThoughts
We're a bit unique as gcc-linaro started from a mature base, running the testsuite takes days, and the product is so big that bzr takes a long time to work on it.
If you have experience in running a master branch or ideas on continious integration please have a read.
FWIW, I like "on trunk", because it's closer to what we do upstream. But for that case, is there any need for a "published" feature branch at all? Is there a problem with committing local changes (or merging a local branch) directly to trunk?
Richard
On Thu, Mar 10, 2011 at 11:51 PM, Richard Sandiford richard.sandiford@linaro.org wrote:
On 9 March 2011 20:56, Michael Hope michael.hope@linaro.org wrote:
We currently use a feature branch / merge request / merge / test / push approach in gcc-linaro. This works fine for a reasonable cost but can mean that patches sit unreviewed and unmerged for up to a month. Ramana, Andrew, and I had a talk about this earlier in the week and I've written up the ideas here: https://wiki.linaro.org/MichaelHope/Sandbox/ReviewThoughts
We're a bit unique as gcc-linaro started from a mature base, running the testsuite takes days, and the product is so big that bzr takes a long time to work on it.
If you have experience in running a master branch or ideas on continious integration please have a read.
FWIW, I like "on trunk", because it's closer to what we do upstream. But for that case, is there any need for a "published" feature branch at all? Is there a problem with committing local changes (or merging a local branch) directly to trunk?
Here's some use cases if we go with 'on trunk':
1. Obvious patch: commit directly 2. New work: gets reviewed upstream, then /could/ be committed directly. 3. Linaro specific fix: reviewed inside Linaro, then committed
With (2) and (3) you need somewhere to do the work. It could live as uncommitted or unpushed work in your repo but this makes it a bit hidden and private.
With (3) you need some way to share the work. This is done in (2) by sending a patch but I think a feature branch that someone can pick up would be nicer.
Short story is that we have a better tool than svn, so feature branches may make some use cases overall easier and more transparent.
-- Michael
I realise this reply is academic; I'm happy to accept the decision. For the record though...
Michael Hope michael.hope@linaro.org writes:
On Thu, Mar 10, 2011 at 11:51 PM, Richard Sandiford richard.sandiford@linaro.org wrote:
On 9 March 2011 20:56, Michael Hope michael.hope@linaro.org wrote:
We currently use a feature branch / merge request / merge / test / push approach in gcc-linaro. This works fine for a reasonable cost but can mean that patches sit unreviewed and unmerged for up to a month. Ramana, Andrew, and I had a talk about this earlier in the week and I've written up the ideas here: https://wiki.linaro.org/MichaelHope/Sandbox/ReviewThoughts
We're a bit unique as gcc-linaro started from a mature base, running the testsuite takes days, and the product is so big that bzr takes a long time to work on it.
If you have experience in running a master branch or ideas on continious integration please have a read.
FWIW, I like "on trunk", because it's closer to what we do upstream. But for that case, is there any need for a "published" feature branch at all? Is there a problem with committing local changes (or merging a local branch) directly to trunk?
Here's some use cases if we go with 'on trunk':
- Obvious patch: commit directly
- New work: gets reviewed upstream, then /could/ be committed directly.
- Linaro specific fix: reviewed inside Linaro, then committed
With (2) and (3) you need somewhere to do the work. It could live as uncommitted or unpushed work in your repo but this makes it a bit hidden and private.
Maybe this is just me, but the way I tend to work with bug-fix "feature" branches is to do the work locally (as I would with any other VCS), then create and publish the branch once I've tested everything and am ready for the changes to be reviewed. I think that publishing the branch in an incomplete state would increase the amount of work for me, and might also increase the noise for everyone else.
With that way of working, sending a patch is just as public as creating a feature branch.
With (3) you need some way to share the work. This is done in (2) by sending a patch but I think a feature branch that someone can pick up would be nicer.
But does anyone actually pick up Linaro GCC feature branches like that in practice, other than to merge them? And is it significantly easier than applying patches?
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) 3) apply fix to new branch, with ChangeLog entry 4) publish new branch in laucnhpad 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.
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 hope this doesn't sound like a grouch. It's certainly not meant to be. I just wanted to clear up what I meant. Like I say, I happily accept the decision.
Richard
On Tue, Mar 15, 2011 at 12:12 AM, Richard Sandiford richard.sandiford@linaro.org wrote:
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 did some quick benchmarks. No comment either way: bzr pull - took 4:06 to pull down and merge a few changes bzr branch 4.5 lp-foo - took 4:35 bzr commit - took 3:08 for a one line change bzr send (puts the delta in a mail message) - took 10:20 bzr merge - took 3:08 for the one-line change into trunk
bzr diff is very fast. The branch for the one-line commit was 23 MB on disk.
A standard work flow of pull / do work / commit /push would be ~7 minutes. A pull / branch / do work / commit / push / merge / commit / push would be ~18 minutes assuming push is free.
-- Michael
On 15 March 2011 08:59, Michael Hope michael.hope@linaro.org wrote:
On Tue, Mar 15, 2011 at 12:12 AM, Richard Sandiford richard.sandiford@linaro.org wrote:
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 did some quick benchmarks. No comment either way: bzr pull - took 4:06 to pull down and merge a few changes bzr branch 4.5 lp-foo - took 4:35 bzr commit - took 3:08 for a one line change bzr send (puts the delta in a mail message) - took 10:20 bzr merge - took 3:08 for the one-line change into trunk
For big trees, I would really recommend you try out 'bzr-colo', which makes it easier to reuse the same working tree across multiple branches. 'bzr colo-branch lp-foo' should be pretty fast, and won't need to create a whole new tree. merge etc may be faster too.
http://doc.bazaar.canonical.com/plugins/en/colo-plugin.html
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:
- develop fix
- 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
- apply fix to new branch, with ChangeLog entry
- 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. :(
- wait for branch to be processed by launchpad (only a few minutes, nothing major)
- ask for a review
- merge to trunk (with the inevitable ChangeLog merge failure that you mentioned).
whereas the upstream way would be:
- develop fix
- ask for a review, attaching patch
- 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
On Tue, Mar 15, 2011, Andrew Stubbs wrote:
I find that bzr is slow - there's no getting around it, but there are some tricks that can help.
Thanks for sharing your tips; also noteworthy, this tip by Martin Pool: http://lists.linaro.org/pipermail/linaro-dev/2011-March/003282.html
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.
Actually, I have a cron jobs which pushes the revisions of the 4.4 branch in the 4.5 repo on Launchpad; I just realized that this was still an issue from your email, so I've looked at the script again and it wasn't dealing with 4.6; I've added a step to copy the 4.6 revs into the 4.5 repo every night, so that should make bzr push fast again for you. (I'm still pushing the revs though, will take a while.)
- wait for branch to be processed by launchpad (only a few minutes, nothing major)
I don't :-)
- merge to trunk (with the inevitable ChangeLog merge failure that you mentioned).
bzr has plugins to merge changelog entries for some types of changelogs; I wonder whether we could use these here. Another option would be to generate a GNU ChangeLog from the bzr log at release time as we do for linaro-image-tools for instance.
On 15 March 2011 22:44, Loïc Minier loic.minier@linaro.org wrote:
7) merge to trunk (with the inevitable ChangeLog merge failure that you mentioned).
bzr has plugins to merge changelog entries for some types of changelogs; I wonder whether we could use these here. Another option would be to generate a GNU ChangeLog from the bzr log at release time as we do for linaro-image-tools for instance.
spiv just put up a proposal[1] to ship the changelog-merging code in bzr core. If that doesn't handle gcc's particular ChangeLog form, please file a bug against bzr with an example and tagged linaro.
[1] https://code.launchpad.net/~spiv/bzr/add-changelog-merge/+merge/53380
-- Martin
We (especially jameinel) looked into this a bit more, and he has a patch that speeds up some of these cases quite a lot: https://bugs.launchpad.net/bzr/+bug/737234.
Martin
On Tue, Mar 15, 2011 at 11:53 PM, Andrew Stubbs andrew.stubbs@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
On 15 March 2011 20:57, Michael Hope michael.hope@linaro.org wrote:
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.
I wanted to share with you some numbers on our changes in bzr 2.4 (final in August), based on the much-appreciated feedback from Linaro. The details are in http://bazaarvcs.wordpress.com/2011/05/17/faster-large-tree-handling but the short story is that local operations like uncommit, revert, and update take a few seconds rather than the multi-minutes that were originally reported. There is still more to do and if you hit other problems please tell us.
Martin
On 17/05/11 17:01, Martin Pool wrote:
I wanted to share with you some numbers on our changes in bzr 2.4 (final in August), based on the much-appreciated feedback from Linaro. The details are in http://bazaarvcs.wordpress.com/2011/05/17/faster-large-tree-handling but the short story is that local operations like uncommit, revert, and update take a few seconds rather than the multi-minutes that were originally reported. There is still more to do and if you hit other problems please tell us.
Thanks Martin, those figures are very promising! :)
You say that 2.4 is due in August, but 2.3.2 already shows some useful improvements, so can you say when that's likely to be available? I believe the PPA stable release is currently still on 2.3.1.
Thanks again
Andrew
On 18 May 2011 10:23, Andrew Stubbs andrew.stubbs@linaro.org wrote:
On 17/05/11 17:01, Martin Pool wrote:
I wanted to share with you some numbers on our changes in bzr 2.4 (final in August), based on the much-appreciated feedback from Linaro. The details are in http://bazaarvcs.wordpress.com/2011/05/17/faster-large-tree-handling but the short story is that local operations like uncommit, revert, and update take a few seconds rather than the multi-minutes that were originally reported. There is still more to do and if you hit other problems please tell us.
Thanks Martin, those figures are very promising! :)
You say that 2.4 is due in August, but 2.3.2 already shows some useful improvements, so can you say when that's likely to be available? I believe the PPA stable release is currently still on 2.3.1.
2.3.3 is now in ppa:bzr/proposed https://launchpad.net/~bzr/+archive/proposed just waiting for a bit of smoke testing before it goes into the main ppa, probably next week. If you would like to install from there and let us know whether there are any regressions or not that would be great.
It will probably also go into maverick-updates in the next couple of weeks. http://wiki.bazaar.canonical.com/UbuntuStableReleaseUpdates
Martin
-
Andrew Stubbs -
James Westby -
Loïc Minier -
Martin Pool -
Michael Hope -
Richard Sandiford -
Robert Nelson