branch not stacked if first push is interrupted

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.

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.

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.

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.

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.

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

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

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

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.