bzr pull/branch shows "Error received from smart server: ('NoSuchRevision',)"

Andrew, I had this specific issue, with the 'NoSuchRevision' traceback in 1.14rc1.

I tried your first suggested workaround: I updated trunk, and tried branching again, but using a bzr+ssh:// url (lp:~mars/....). That caused bug 354036, 'AbsentContentFactory', to occur.

Next, I tried pulling from the sftp:// url, which worked perfectly.

So, pulling trunk/, and branching from the sftp:// URL should serve as a workaround for both this and bug 354036, without having to downgrade bzr.

On Thu, Apr 30, 2009 at 12:54:16AM -0000, Andrew Bennetts wrote:
> *** This bug is a duplicate of bug 360791 ***
> https://bugs.launchpad.net/bugs/360791
>
> Bjorn: which error? This bug report is confusing, as several distinct
> issues have been mentioned.

I was referring to the NoRevisionError that Tim got. Here's the
traceback I got:

    https://bugs.edge.launchpad.net/bzr/+bug/360791

It certainly sounds like bug 360791, since I getting this error on my
laptop, where it worked fine on my desktop (which had an up to date copy
of the stacked-on branch in the repo).

Again, bumping to critical as we continue to create broken branches with bzr.dev

On Mon, 2009-05-04 at 18:56 +0000, Martin Albisetti wrote:
> Again, bumping to critical as we continue to create broken branches with
> bzr.dev

Beuno, this isn't a broken branch bug, and there is a workaround in
place already (which there isn't for the ghost variation of same). See
the workaround notes in the description.

-Rob

I see. It's still a show-stopper for anyone using stacked branches, so I still think it should be treated as critical.
Considering this piles up on top of the 1.13 AbsentContentFactory, the fact that there's a workaround doesn't make up for the fact that stacked branches have been broken for a month and a half or two.
Yes, I'm being overly annoying and exagerated, but the issue has been very disruptive for any heavy users of launchpad and bzr.

On Mon, 2009-05-04 at 22:25 +0000, Martin Albisetti wrote:
> I see. It's still a show-stopper for anyone using stacked branches, so
> I still think it should be treated as critical.

Indeed, and you'll note neither Martin Pool nor I have disagreed and
changed the importance field.

> Considering this piles up on top of the 1.13 AbsentContentFactory, the
> fact that there's a workaround doesn't make up for the fact that
> stacked branches have been broken for a month and a half or two.

For users of released bzr's they have been broken for 4 days, and only
by this bug. bzr 1.14 is the first bzr to suffer streaming issues with
stacked branches, and it was released May 1st.

> Yes, I'm being overly annoying and exagerated, but the issue has been
> very disruptive for any heavy users of launchpad and bzr.

For folk running *beta releases or trunk*, yes. But people use that to
help us find issues, and should know how to drop back to a released
version.

We're working hard to fix the issues, and as I note, users using
released bzr's have the bugfix for the ACF bug (which 1.13 doesn't
suffer, as it doesn't stream from stacked branches, and *all* bzr's
before 1.13.2 create the situation for it, if you want to measure by
that standard,measure since 1.6).

-Rob

    def test_stacked_pull_more_than_stacking_has_bug_360791(self):
        # When pulling some fixed amount of content that is more than
the
        # source has (because some is coming from a fallback branch, no
error
        # should be received. This was reported as bug 360791.
        # Need three branches: a trunk, a stacked branch, and a
preexisting
        # branch pulling content from stacked and trunk.
        self.setup_smart_server_with_call_log()
        trunk = self.make_branch_and_tree('trunk',
format="1.9-rich-root")
        r1 = trunk.commit('start')
        stacked_branch = trunk.branch.create_clone_on_transport(
            self.get_transport('stacked'), stacked_on=trunk.branch.base)
        local = self.make_branch('local', format='1.9-rich-root')
 local.pull(stacked_branch) #boom

This fix once reviewed in bzr land should be cherrypicked onto the lp production bzr server - its a server side fix.

r4342 in trunk has this.

This should be backported to jaunty's bzr too.

Won't fix in the 1.14 series, fixed in 1.15