This was originally an internal email from Sidnei Da Silva.  Below, it's edited/paraphrased in a few places, to make it comprehensible outside its original context.

{{{
Hi all,

Following up on the reports of the Launchpad strategy of "bridging the
gap", I would like to present a story, to get an idea of where do we
stand and where are we headed to.

Today I had to make a branch for fixing a bug on the zope.testing
project. The project is hosted on svn.zope.org, using Subversion. So I
thought I would use bzr (through bzr-svn) to hack on it.

Branching from Subversion worked just fine. I made some changes on my
local branch and then decided it was ready. The next step involved
search for information about 'dpush', of which I couldn't find much.
This is where things started breaking down.

The first thing I tried was to create the remote branch by doing 'bzr
dpush <url-to-non-existing-remote-branch-in-svn>', to which I was
greeted with a message that the remote branch didn't exist. Fine
enough, I created the remote branch and tried to 'dpush' to it...
which doesn't work, since the remote branch has a new revision not
present in the local branch.

Various combinations of 'bzr merge' and 'bzr pull' later, I decided to
start fresh and created a new local branch from the newly-created
remote Subversion branch, merged the changes from my existing local
bzr branch into it and then doing 'bzr dpush' worked. Phew.

Now, it turns out I would like my peers to be able to review this
branch. Except it's now hosted in Subversion, so I cannot use Merge
Proposals (would be nice to create Merge Proposals for remote
branches, eh?). Fine, I thought. I can just push my local bzr branch
to Launchpad, can't I?

So I tried that. And it failed with a cryptic message about the
repository format being different, due to the fact that there's a
lp:zope.testing branch, which is a vcs-import branch, which is set as
the 'Development Focus', which turns out that push tries to stack on.
At this point I felt a little hopeless, but fear not! I asked for help
on #launchpad-code and Jono presented me some options.

a) Removing the 'Development Focus' toggle from lp:zope.testing
b) Pushing without stacking (which seems like there's no command line
option for)
c) Branching from lp:zope.testing, re-applying my changes and pushing
the new branch to Launchpad

I picked option c), as that's what made more sense to me. But that now
leaves me with two bugfix branches which have no relationship at all
between them, which is bad. That is, I cannot simply merge between
them, I have to use diff and patch. Not nice.

If I picked b), my understanding is that the Merge Proposal would not
work, since lp:zope.testing has no relation at all with the original
branch in Subversion (due to the fact Launchpad is not using bzr-svn
yet, or wasn't last I heard of). My understanding is that this is in
the process of being fixed, pending having Launchpad running on Python
2.5.

If I picked a), I could have pushed a bzr-svn-branched trunk to
Launchpad, set it as the Development Focus and stack-on it, and then I
could take my existing bugfix branch that I branched from Subversion
and pushed it to Launchpad, and Merge Proposals would work with that,
but then this new trunk would not be automatically updated by
vcs-imports, and would be of limited use to me or anyone else.

That said, I would like to confirm that this describes what the
average experience for someone trying to interop with upstreams is at
the moment, or if I did something completely wrong somewhere.

As for what it should be like, if I got this right, once Launchpad
moves to Python 2.5 and uses bzr-svn, then it won't matter if I
initially branch from the original Subversion repository or from
lp:zope.testing (a vcs-import of the Subversion repository): they
would both create equivalent branches, and I would be able to push my
bugfix branch to Launchpad and create a Merge Proposal for it. That
would indeed make the experience a lot better and would be a very
compelling reason to have someone else at least consider using bzr as
their DVCS for interacting with upstream. Does that reflect what the
future plan is?

 Sidnei
}}}