Comment 4 for bug 818138
Revision history for this message
| John A Meinel (jameinel) wrote Re: absurd upload size on second push | #4 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Looking at the directories directly:
http://
vs
http://
There are a few things:
1) It certainly appears to have uploaded all of the history of the repository.
2) Bug #465517 is that it was pushing the whole repository, not the whole ancestry of a given branch. Eg, I have bzr-rewrite in the same repository as bzr. bug #465517 was that 'bzr push' && ^C && 'bzr push' would try to push up all of *bzr* into the *bzr-rewrite* target.
3) Because of the ^C and re-push, the branch did not end up stacked on the development focus:
http://
(there should be a 'stacked_
4) The bug is that the second 'bzr push' doesn't see that it should be stacked by-default. I believe the cause is:
a) The config stating that it should be stacked is a virtual file in ~/ubuntu-on-ec2/ (AIUI). We fake a .bzr/control.conf file.
b) After the first push, we have created the .bzr/ directory and .bzr/repository but *not* the .bzr/branch. So the first process does see that the branch should be stacked, but it won't create that branch until the repository fetch has finished.
We create the branch last because we didn't want a psuedo-branch to confuse things. The branch can't say that it is at the target tip revision, because that content has not been pushed to the repository yet. However, I think we've had enough experience to show that we can probably just set the branch tip to 'null:', finish the fetch, and then update the branch tip to the target revision.
I don't think this needs to be critical, because it isn't any sort of regression. We've been doing since stacked branches were first created.