Is there a better structure for this local-Bzr-Team, upstream Svn branch, situation?

[John Barstow]

My solution to this meets similar requirements.

1.  I use bzr to check out the svn code (so it's a bound branch).
Let's call this proj.svn
2.  I then create an unbound branch - 'bzr branch proj.svn proj.local'
3.  All work happens in a branch of proj.local (usually we create
feature branches)
4.  Changes get pushed to proj.local, this acts as our integration
branch. In practice a lot of times we bzr merge a feature branch into
proj.local then delete the feature branch.
5.  I go to proj.svn, do a 'bzr up',(optionally go to proj.local and
'bzr pull proj.svn', back to proj.svn) then  'bzr merge proj.local'.
     I usually do the middle part due to years of svn conditioning, it
does mean if a merge conflict ever happens it gets resolved in the
integration branch.
6.  Finally commit to svn with 'bzr commit'.

The nice thing about this strategy is that it works pretty well
regardless of the upstream repository format; I use the almost exactly
the same pattern with our upstream TFS repository except the initial
branch is not bound (which is why the initial release of bzr-tfs
happens to support exactly this subset of operations {branch, pull,
merge, commit}).