Hi all,
We seem to have had an accident!
This morning I merged one of my patches to lp:gcc-linaro/4.6, and this afternoon I got an email from Launchpad notifying me that a mystery revision had been deleted.
It seems that Richard has somehow overwritten my change with his. Luckily I've spotted it and will fix it now, but it could very easily have got lost.
I'm not sure what's happened here, but I'm pretty sure bzr does not just do this silently. I thought you needed to specify --overwrite to do this on purpose, but perhaps there's a bzr bug here?
Anyway, could everyone please be very careful when they do bzr push to the release branches.
Thanks
Andrew
OK, I think I've got to the bottom of this now, with a bit of help from the people at #bzr.
What Richard must have done is merged lp:gcc-linaro/4.6 *to* his development branch, and then pushed that branch with --overwrite, thus rewriting history. :(
I've now changed the configuration of the branch such that it shouldn't be permitted any more. It should only permit revisions to be appended from now on.
I also changed 4.4 and 4.5 branches likewise.
Andrew
On 04/05/11 16:55, Andrew Stubbs wrote:
Hi all,
We seem to have had an accident!
This morning I merged one of my patches to lp:gcc-linaro/4.6, and this afternoon I got an email from Launchpad notifying me that a mystery revision had been deleted.
It seems that Richard has somehow overwritten my change with his. Luckily I've spotted it and will fix it now, but it could very easily have got lost.
I'm not sure what's happened here, but I'm pretty sure bzr does not just do this silently. I thought you needed to specify --overwrite to do this on purpose, but perhaps there's a bzr bug here?
Anyway, could everyone please be very careful when they do bzr push to the release branches.
Thanks
Andrew
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
On 04/05/11 17:48, Andrew Stubbs wrote:
What Richard must have done is merged lp:gcc-linaro/4.6 *to* his development branch, and then pushed that branch with --overwrite, thus rewriting history. :(
Just to be clear, here's the correct way to do a merge:
[assuming you want to reuse an existing branch] bzr pull --overwrite lp:gcc-linaro/4.6 bzr merge lp:.....whatever..... [...resolve-conflicts....] bzr resolve bzr commit bzr push lp:gcc-linaro/4.6
In other words, please merge *from* development branches *to* release branches.
Thanks
Andrew
Sorry for all the trouble.
Andrew Stubbs ams@codesourcery.com writes:
On 04/05/11 17:48, Andrew Stubbs wrote:
What Richard must have done is merged lp:gcc-linaro/4.6 *to* his development branch, and then pushed that branch with --overwrite, thus rewriting history. :(
For the record, I certainly didn't do anything involving --overwrite, which I hadn't heard of until now.
Just to be clear, here's the correct way to do a merge:
[assuming you want to reuse an existing branch] bzr pull --overwrite lp:gcc-linaro/4.6 bzr merge lp:.....whatever..... [...resolve-conflicts....] bzr resolve bzr commit bzr push lp:gcc-linaro/4.6
In other words, please merge *from* development branches *to* release branches.
And FWIW, this is what I thought I'd done (and what I did for other merges that appeared to go successfully).
Specifically, I have the usual shared repo, with subdirectories for individual branches. So I have a gcc-linaro subdirectory that tracks the main tree, a 4.6 subdirectory that tracks gcc-linaro/4.6, and a subdirectory for each of my branches.
When I did the merge, I "cd"ed into the 4.6 directory and ran:
bzr merge lp:~rsandifo/gcc-linaro/lp-714921-4.6
This appeared to work as expected. The only changes were to gcc/dwarf2out.c and ChangeLog.linaro, with the usual conflict in the latter. The change before mine in ChangeLog.linaro was dated 2011-05-02, which is much more recent than the branch, so that too felt "right". (The branch was cut on 2011-04-21.)
I did the usual "bzr diff" before committing, and as expected, the only differences were in the two files mentioned above. So I think it really was a merge _to_ 4.6 rather than a merge _from_ 4.6. If it had been the other way, I'd have expected a diff of the changes in 4.6 since I cut my branch.
However, when I tried to push the changes back, bzr told me that the branches had "diverged". I assumed that this was bzr's way of telling me that someone had pushed a new revision to 4.6 while I was doing the merge. This seemed entirely plausible -- I think there was a window of 10 minutes or more -- so I'm afraid I didn't even question that assumption. I'll ask now what I should have asked yesterday: what does bzr do when there's this kind of clash?
Anyway, the bzr help page seemed to suggest that merging in the new 4.6 revision was the Right Thing to do. I'm afraid that, once again, it felt so natural to resolve push conflicts this way that I didn't even question the assumption. I did the merge, and as expected, there was only one new commit: your change from yesterday. So I committed the merge and pushed again. bzr was happy this time. I didn't need any special options to push. Perhaps if I had, overdue alarm bells might finally have rung.
Once again, I'm sorry for the screw-up. I should have been more circumspect.
Richard
On 05/05/11 08:43, Richard Sandiford wrote:
Anyway, the bzr help page seemed to suggest that merging in the new 4.6 revision was the Right Thing to do. I'm afraid that, once again, it felt so natural to resolve push conflicts this way that I didn't even question the assumption. I did the merge, and as expected, there was only one new commit: your change from yesterday. So I committed the merge and pushed again. bzr was happy this time. I didn't need any special options to push. Perhaps if I had, overdue alarm bells might finally have rung.
OK, so if I understand correctly, the merge was done correctly, but then the push didn't work. So far so good.
But then, merging from 4.6 to synchronize the branches somehow convinced bzr that it was ok to push without --overwrite, even though that would rewrite history. Yuck, that's horrible!
So the end result is that the source tree is indistinguishable from what it would have been, but the bzr log is totally screwed up. :(
Once again, I'm sorry for the screw-up. I should have been more circumspect.
Who knew bzr could even do this?! :(
Anyway, I've set the branches to append only mode, so hopefully this kind of 'smart' feature is defeated.
BTW, there is a bzr plugin named 'rewrite' that adds a 'rebase' command that works better in the case of diverged branches. It's slow as hell though.
Andrew
Andrew Stubbs ams@codesourcery.com writes:
On 05/05/11 08:43, Richard Sandiford wrote:
Anyway, the bzr help page seemed to suggest that merging in the new 4.6 revision was the Right Thing to do. I'm afraid that, once again, it felt so natural to resolve push conflicts this way that I didn't even question the assumption. I did the merge, and as expected, there was only one new commit: your change from yesterday. So I committed the merge and pushed again. bzr was happy this time. I didn't need any special options to push. Perhaps if I had, overdue alarm bells might finally have rung.
OK, so if I understand correctly, the merge was done correctly, but then the push didn't work. So far so good.
But then, merging from 4.6 to synchronize the branches somehow convinced bzr that it was ok to push without --overwrite, even though that would rewrite history.
Seems that way. FWIW, I thought when mecurial did this kind of thing, it preserved the history of both strands. Maybe git does too; I've never used git for a shared-push repo like this. I hadn't realised history could be lost.
But just to be clear, in the kind of situation where person A has pushed a new revision while person B was doing a merge, what should person B do when the push fails? Should they undo the local merge, pull, then merge again? Or is there a better way? Do you mean that:
BTW, there is a bzr plugin named 'rewrite' that adds a 'rebase' command that works better in the case of diverged branches. It's slow as hell though.
this is the right thing to do instead?
Once again, I realise I should have asked this _before_ messing things up, sorry. :-(
Richard
On 05/05/11 09:32, Richard Sandiford wrote:
But just to be clear, in the kind of situation where person A has pushed a new revision while person B was doing a merge, what should person B do when the push fails? Should they undo the local merge, pull, then merge again? Or is there a better way? Do you mean that:
BTW, there is a bzr plugin named 'rewrite' that adds a 'rebase' command that works better in the case of diverged branches. It's slow as hell though.
this is the right thing to do instead?
Yes, with the rewrite plugin you can just do:
bzr rebase [while conflict] [...fix conflict...] bzr rebase-continue bzr push
However, I have to say that doing it manually might be faster (if you don't have many commits) and you don't need the plugin:
bzr pull --overwrite /* wipe local changes */ bzr merge .... [...fix conflicts...] bzr commit bzr push
Andrew
On 5 May 2011 10:32, Richard Sandiford richard.sandiford@linaro.org wrote:
Andrew Stubbs ams@codesourcery.com writes:
On 05/05/11 08:43, Richard Sandiford wrote:
Anyway, the bzr help page seemed to suggest that merging in the new 4.6 revision was the Right Thing to do. I'm afraid that, once again, it felt so natural to resolve push conflicts this way that I didn't even question the assumption. I did the merge, and as expected, there was only one new commit: your change from yesterday. So I committed the merge and pushed again. bzr was happy this time. I didn't need any special options to push. Perhaps if I had, overdue alarm bells might finally have rung.
OK, so if I understand correctly, the merge was done correctly, but then the push didn't work. So far so good.
But then, merging from 4.6 to synchronize the branches somehow convinced bzr that it was ok to push without --overwrite, even though that would rewrite history.
Seems that way. FWIW, I thought when mecurial did this kind of thing, it preserved the history of both strands. Maybe git does too; I've never used git for a shared-push repo like this. I hadn't realised history could be lost.
Hi guys, all of the history is still preserved, as you can see by running 'bzr log -n0' on that branch. What has happened is that the last few revisions of trunk are now shown as being merged in to Richard's work, rather than his work being merged into trunk.
Perhaps the main issue here is https://bugs.launchpad.net/launchpad/+bug/777880 which is that the Launchpad message is a bit disturbing and offputting; also the bzr ui for doing the merge could be clearer.
But just to be clear, in the kind of situation where person A has pushed a new revision while person B was doing a merge, what should person B do when the push fails? Should they undo the local merge, pull, then merge again? Or is there a better way? Do you mean that:
What I would probably recommend is: switch to a checkout of trunk, pull from the upstream trunk, then merge from your local branch, commit, and push. You can also use 'bzr bind lp:linaro-gcc' which will do the commit synchronously with updating the trunk branch and then there is no window it can get out of date.
BTW, there is a bzr plugin named 'rewrite' that adds a 'rebase' command that works better in the case of diverged branches. It's slow as hell though.
I'd like to know more about the case where it's slow, because we have fixed up some of the other performance issues that were biting Linaro. Could you tell me more, or if you like file a bug at http://pad.lv/fb/bzr-rebase saying what you're running on what branches and what speed it is?
this is the right thing to do instead?
rebase is a good option if you want to make the history look like you just did the work on top of the tip revision in the first place, but merging is fine too -- really it is up to the Linaro devs to decide how they want to run it.
Once again, I realise I should have asked this _before_ messing things up, sorry. :-(
You didn't really do anything wrong here. Sorry it was confusing.
Martin
On 05/05/11 15:42, Martin Pool wrote:
I'd like to know more about the case where it's slow, because we have fixed up some of the other performance issues that were biting Linaro. Could you tell me more, or if you like file a bug at http://pad.lv/fb/bzr-rebase saying what you're running on what branches and what speed it is?
Last time I used it, I took lp:~ams-codesourcery/gcc-linaro/cs-merge-20110413, and rebased it to lp:gcc-linaro. This took at least an hour to run, possibly 2-3 hours, I don't recall - I got bored and went to do something else.
Note that some of the revisions on cs-merge-20110413 have now been committed to lp:gcc-linaro, so to repeat the experiment you'll need to only rebase as far as r99496, I think. It's actually only 3 revisions difference, I think.
The GCC source tree is huge, and has a long history, so doing just about anything with it in BZR takes a while, and consumes a lot of memory. I've not tried using git with the full GCC history, but I have tried it with even larger sourcebases (GCC, binutils, GDB, etc. all combined into one repo), and I can say it was much quicker, although still gives enough time to read a few emails.
Andrew
On 5 May 2011 17:08, Andrew Stubbs ams@codesourcery.com wrote:
On 05/05/11 15:42, Martin Pool wrote:
I'd like to know more about the case where it's slow, because we have fixed up some of the other performance issues that were biting Linaro. Could you tell me more, or if you like file a bug at http://pad.lv/fb/bzr-rebase saying what you're running on what branches and what speed it is?
Last time I used it, I took lp:~ams-codesourcery/gcc-linaro/cs-merge-20110413, and rebased it to lp:gcc-linaro. This took at least an hour to run, possibly 2-3 hours, I don't recall - I got bored and went to do something else.
Note that some of the revisions on cs-merge-20110413 have now been committed to lp:gcc-linaro, so to repeat the experiment you'll need to only rebase as far as r99496, I think. It's actually only 3 revisions difference, I think.
I filed https://bugs.launchpad.net/bzr-rewrite/+bug/777920 to track this. I think it will have been improved a fair bit by John's recent work on huge-tree workingtree performance work (which sped up some things like revert 8x) but there's probably more to do. That work is in bzr 2.4beta, which you can get from eg ppa:bzr/daily.
Martin
On 05/05/11 16:22, Martin Pool wrote:
I filedhttps://bugs.launchpad.net/bzr-rewrite/+bug/777920 to track this. I think it will have been improved a fair bit by John's recent work on huge-tree workingtree performance work (which sped up some things like revert 8x) but there's probably more to do. That work is in bzr 2.4beta, which you can get from eg ppa:bzr/daily.
I certainly have witnessed revert being very slow.
In fact, I'd say it feels quicker to run "bzr st" and then do "bzr revert" naming individual files. Maybe that's illusory, but it's certainly quicker to revert individual files if you already have the list to hand. Of course, that doesn't revert merge notes, so it's perhaps not exactly the same.
Uncommit is another command that seems unreasonably slow. It really shouldn't be that hard to do a "patch -R" and update some metadata somewhere, but clearly there's a lot more to it than that!
Andrew
On 5 May 2011 18:19, Andrew Stubbs andrew.stubbs@linaro.org wrote:
On 05/05/11 16:22, Martin Pool wrote:
I filedhttps://bugs.launchpad.net/bzr-rewrite/+bug/777920 to track this. I think it will have been improved a fair bit by John's recent work on huge-tree workingtree performance work (which sped up some things like revert 8x) but there's probably more to do. That work is in bzr 2.4beta, which you can get from eg ppa:bzr/daily.
I certainly have witnessed revert being very slow.
In fact, I'd say it feels quicker to run "bzr st" and then do "bzr revert" naming individual files. Maybe that's illusory, but it's certainly quicker to revert individual files if you already have the list to hand. Of course, that doesn't revert merge notes, so it's perhaps not exactly the same.
I think that's consistent with the bug that was recently fixed. If you still see this in current bzr 2.4beta, please let me know.
Uncommit is another command that seems unreasonably slow. It really shouldn't be that hard to do a "patch -R" and update some metadata somewhere, but clearly there's a lot more to it than that!
I think that's the same.
Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 5/5/2011 11:22 PM, Martin Pool wrote:
On 5 May 2011 18:19, Andrew Stubbs andrew.stubbs@linaro.org wrote:
On 05/05/11 16:22, Martin Pool wrote:
I filedhttps://bugs.launchpad.net/bzr-rewrite/+bug/777920 to track this. I think it will have been improved a fair bit by John's recent work on huge-tree workingtree performance work (which sped up some things like revert 8x) but there's probably more to do. That work is in bzr 2.4beta, which you can get from eg ppa:bzr/daily.
I certainly have witnessed revert being very slow.
In fact, I'd say it feels quicker to run "bzr st" and then do "bzr revert" naming individual files. Maybe that's illusory, but it's certainly quicker to revert individual files if you already have the list to hand. Of course, that doesn't revert merge notes, so it's perhaps not exactly the same.
I think that's consistent with the bug that was recently fixed. If you still see this in current bzr 2.4beta, please let me know.
It hasn't actually landed yet because the revert patch conflicted with TreeReferences, which I had an initial fix for, but had yet more fallout in another section with TreeReferences. (nested-subtrees which is unfinished work in our codebase.)
I hope to have that finished off and landed today.
Uncommit is another command that seems unreasonably slow. It really shouldn't be that hard to do a "patch -R" and update some metadata somewhere, but clearly there's a lot more to it than that!
I think that's the same.
Martin
Uncommit has to rewrite the whole dirstate file because we are storing the inventory of the basis revision to make things like "bzr st" fast. (uncommit trivially moves the branch pointer, and then not-quite-so-trivially tells the working tree that it has a new basis revision.)
It is possible that we could be lighter weight about the basis revision change. Instead of telling it "you are now pointing at X", tell it "you are pointing at X, and here is the delta between Y and X".
I think the main issue for uncommit (minutes) is that it would walk the whole basis inventory from the repository in a bad way. *That* should be fixed in bzr-2.4b2 (we'll walk the basis inventory in a faster way, ~10s). If we did a delta approach, we could probably get that down to <1s.
Rewriting the dirstate file itself would then be the primary bottleneck, I think.
In 2.4b? most commands that took >3min in my testing dropped into the <30s range because of improved ordering while walking the inventory. There are still a few more that can be improved a bit further.
John =:->
On 06/05/11 07:11, John Arbash Meinel wrote:
In 2.4b? most commands that took>3min in my testing dropped into the <30s range because of improved ordering while walking the inventory. There are still a few more that can be improved a bit further.
Any idea when these improvements are likely to hit the PPA stable release?
I can try out other versions on my local machine, but I won't get it on the build server until it's officially stable.
Thanks
Andrew
On 6 May 2011 10:13, Andrew Stubbs ams@codesourcery.com wrote:
On 06/05/11 07:11, John Arbash Meinel wrote:
In 2.4b? most commands that took>3min in my testing dropped into the <30s range because of improved ordering while walking the inventory. There are still a few more that can be improved a bit further.
Any idea when these improvements are likely to hit the PPA stable release?
I can try out other versions on my local machine, but I won't get it on the build server until it's officially stable.
2.4 will be frozen in August (ahead of the Ubuntu 11.10 freeze), and shortly after that it will go into ppa:bzr/ppa. Before then it's just the daily and beta ppas.
Martin
linaro-toolchain@lists.linaro.org
-
Andrew Stubbs -
Andrew Stubbs -
John Arbash Meinel -
Martin Pool -
Richard Sandiford