[Bug 818138] Re: absurd upload size on second push
John A Meinel
john at arbash-meinel.com
Tue Aug 9 12:42:33 UTC 2011
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/9/2011 10:57 AM, Scott Moser wrote:
> On Fri, 5 Aug 2011, John A Meinel wrote:
>
>> 3) Because of the ^C and re-push, the branch did not end up stacked
>> on the development focus:
>> http://bazaar.launchpad.net/~ubuntu-on-ec2/live-build/cloud-images/.bzr/branch/branch.conf
>>
>>
(there should be a 'stacked_on_location' there.)
>
> There was no control-C . At least, if I reported that there was, I
> am uncertain of that. Instead, the initial push just fails with the
> message above.
>
> So at very least there is a bug there.
>
Your initial push doesn't say anything about failing, just taking a while.
Your symptoms match the case when a bzr meta-directory exists, but the
branch directory does not. (a .bzr/ dir exists, but .bzr/branch/ is
missing.) That can happen if someone starts pushing to a branch and
interrupts it. The *next* push would show the symptoms you describe. (it
would fail to notice that the branch should be stacked, so create a
complete new copy of the history in the target location.)
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk5BKzkACgkQJdeBCYSNAAPaMwCgmeyZz95O+/FFsGswMZbwVb2/
35cAn3n88lBJfjKdfsRUxxFTGspUEW5N
=0BgU
-----END PGP SIGNATURE-----
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to bzr in Ubuntu.
https://bugs.launchpad.net/bugs/818138
Title:
branch not stacked if first push is interrupted
Status in Bazaar Version Control System:
Confirmed
Status in “bzr” package in Ubuntu:
New
Bug description:
I did the following:
$ lp:~ubuntu-on-ec2/ubuntu-on-ec2/live-build live-build.dist
$ bzr branch live-build.dist -r 1811 cloud-images
$ cd cloud-images
$ # manually apply revision 1813, 1814 , the point of this was to ditch my accidental merge in 1812.
Then
$ bzr push lp:~ubuntu-on-ec2/live-build/cloud-images
This transport does not update the working tree of: bzr+ssh://bazaar.launchpad.net/~ubuntu-on-ec2/live-build/cloud-images/. See 'bzr help working-trees' for more information.
Created new branch.
The above too a while (minutes). I wondered why the message , which I
suppose is due to repository formats or something, and then tried
again:
$ bzr push lp:~ubuntu-on-ec2/live-build/cloud-images
#### 20 minutes or more later:
254912kB 244kB/s | Fetching revisions:Inserting stream
259070kB 237kB/s | Fetching revisions:Inserting stream
Eventually that reported:
No new revisions to push.
If I do the following on oneiric, i'll see something like:
$ bzr branch lp:~ubuntu-on-ec2/live-build/cloud-images
273670kB 1957kB/s \ Fetching revisions:Inserting stream:Estimate 104073/106426
324886kB 848kB/s / Fetching revisions:Inserting stream:Estimate 113712/116014
327077kB 34kB/s - Build phase:Building tree 42/710
Branched 1813 revision(s).
$ du -hs cloud-images/
314M cloud-images/
However, if I do the same thing on a lucid system
$ bzr --version | head -n 1
Bazaar (bzr) 2.1.4
$ bzr branch lp:~ubuntu-on-ec2/live-build/cloud-images
$ du -hs cloud-images
$ du -hs cloud-images/
52M cloud-images/
So I guess i have 2 issues:
a.) why the "This transport does not update the working tree" message
b.) why the 250M+ upload for "no revisions to push"
c.) why am I do I waste 6X the space on oneiric that I would for the same thing on lucid.
ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: bzr 2.4.0~beta5-2ubuntu1
ProcVersionSignature: Ubuntu 3.0.0-7.8-generic 3.0.0
Uname: Linux 3.0.0-7-generic x86_64
Architecture: amd64
Date: Fri Jul 29 11:54:05 2011
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Beta amd64 (20100318)
PackageArchitecture: all
ProcEnviron:
PATH=(custom, user)
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: bzr
UpgradeStatus: Upgraded to oneiric on 2010-11-15 (255 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/bzr/+bug/818138/+subscriptions
More information about the foundations-bugs
mailing list