branch not stacked if first push is interrupted

Bug #818138 reported by Scott Moser
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar
Confirmed
High
canonical-bazaar
Breezy
Triaged
High
Unassigned
bzr (Ubuntu)
Triaged
High
Unassigned

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)

Revision history for this message
Scott Moser (smoser) wrote :
Scott Moser (smoser)
description: updated
Revision history for this message
Martin Pool (mbp) wrote : Re: [Bug 818138] Re: absurd upload size on second push

I think this is a dupe about the first push being interrupted, and the
workaround is to delete the branch through the lp ui and then push it
again. Sorry for the trouble.

Revision history for this message
Martin Pool (mbp) wrote : Re: absurd upload size on second push

The other bug I was thinking of was bug 465517, but is supposed to be fixed ahead of 2.4b5, and it that wouldn't explain you seeing different results running apparently the same command on lucid and oneiric. So more investigation seems to be needed.

Martin Pool (mbp)
Changed in bzr:
status: New → Confirmed
importance: Undecided → Critical
Revision history for this message
John A Meinel (jameinel) wrote :

Looking at the directories directly:
http://bazaar.launchpad.net/~ubuntu-on-ec2/ubuntu-on-ec2/live-build/.bzr/repository/packs/
vs
http://bazaar.launchpad.net/~ubuntu-on-ec2/live-build/cloud-images/.bzr/repository/packs/

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://bazaar.launchpad.net/~ubuntu-on-ec2/live-build/cloud-images/.bzr/branch/branch.conf
(there should be a 'stacked_on_location' there.)
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.

Changed in bzr:
importance: Critical → High
assignee: nobody → canonical-bazaar (canonical-bazaar)
summary: - absurd upload size on second push
+ branch not stacked if first push is interrupted
Revision history for this message
Scott Moser (smoser) wrote : Re: [Bug 818138] Re: absurd upload size on second push

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.

Revision history for this message
Scott Moser (smoser) wrote :

Additionally,
  Why would a perfectly clean 'bzr branch' done on 10.04 version of bzr result in a checkout that takes 52M and the same on a recent bzr result in 314M.

Revision history for this message
John A Meinel (jameinel) wrote :

-----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-----

Revision history for this message
John A Meinel (jameinel) wrote : Re: [Bug 818138] Re: branch not stacked if first push is interrupted

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/9/2011 10:59 AM, Scott Moser wrote:
> Additionally, Why would a perfectly clean 'bzr branch' done on 10.04
> version of bzr result in a checkout that takes 52M and the same on a
> recent bzr result in 314M.
>

This seems unrelated to this report, though you're welcome to open a new
bug. We'd need a lot more details, though, to figure out what is
actually going on. What commands are you actually running, from where,
to where. "branch" technically can't create a 'checkout', etc. Are you
seeing content in .bzr, are you in a shared repository for the former
but not the later, etc.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5BK5gACgkQJdeBCYSNAAMMpACfZTl7w1pUc0PsTo9Y13Xpi4Ie
E2sAoMsLkcqQrdohIAd735/PK87Q/gkP
=XsBD
-----END PGP SIGNATURE-----

Revision history for this message
Scott Moser (smoser) wrote :

I suggest that you attempt to reproduce this issue.
The steps to do so are completely available above. I would guess that you could do them entirely with your user instead of ~ubuntu-on-ec2.

regarding the difference in size, reproducibility is as easy as:
On Lucid:
 $ bzr branch lp:~ubuntu-on-ec2/live-build/cloud-images

On Oneiric:
  $ bzr branch lp:~ubuntu-on-ec2/live-build/cloud-images

Revision history for this message
Jelmer Vernooij (jelmer) wrote :

Until a recent commit from John, newer versions of bzr (at least the one currently in Oneiric) would not just fetch all revisions in the mainline but also all revisions pointed to by tags.

It looks like lp:~ubuntu-on-ec2/live-build/cloud-images has a lot of tags for revisions unrelated to the mainline.

Jelmer Vernooij (jelmer)
Changed in bzr (Ubuntu):
status: New → Triaged
importance: Undecided → High
Jelmer Vernooij (jelmer)
tags: added: check-for-breezy
Jelmer Vernooij (jelmer)
Changed in brz:
importance: Undecided → High
status: New → Triaged
tags: added: stacking
removed: check-for-breezy
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.