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