Using bzr-svn and Launchpad

[Eugene Wee]

On Sat, May 2, 2009 at 4:10 AM, Jelmer Vernooij <jelmer at samba.org> wrote:
> If you use Launchpad's vcs-imports service to do the import you can't
> use bzr-svn to push back to upstream; the two aren't integrated (at
> least not yet) and branches created with one aren't compatible with the
> other.

Right, thanks for the clarification :)

> The EOL property is only picked up in native Subversion working copies,
> not in Bazaar branches (as there is no way to store svn file properties
> in bzr branches/working trees). In native Bazaar branches you can still
> have eol handling, but you'll need to configure it manually (in
> .bzr/branch/rules or ~/.bazaar/rules).

Ah, I missed the part about native Subversion working copies. What
exactly is the purpose of bzr-svn being able to handle Subversion
working copies? Is it just so that a Subversion client need not be
installed?

Unfortunately, the Boost Subversion server enforces the requirement
that both svn:mime-type and svn:eol-style be set for all files
committed. As such, it appears that I must use a Subversion working
copy with a Subversion client.

I am considering one (imperfect) way out that does not involve bzr-svn:
1. Create a new bzr branch, then svn checkout my Boost SVN trunk into
it. (Apparently I cannot reverse the order with bzr-svn installed.)
2. Add all the files except .svn directories and their contents, to be
under bzr version control.
3. Push the bzr branch to Launchpad.
4. Setup my "shared tree across branches" workspace with the trunk as
a mirror of the trunk on Launchpad.
5. svn checkout my Boost SVN trunk into the trunk mirror. (Not sure
about what happens here since the files would be duplicated. I might
need to delete everything except the .bzr directory and .bzrignore
first.)

Now, development proceeds with feature branches using bzr. After I am
done with a feature branch, I bzr switch to the trunk mirror, bzr
merge and bzr commit. Then, if I have online access, I svn update,
resolve conflicts, and svn commit. Now, I bzr commit again, and
finally bzr push.

This way I get to commit offline while being able to keep the
"official" Boost SVN repository updated with history that makes sense.
However, one shortcoming is that the bzr branches would lack the
previous history from SVN, but that might not matter so much since it
is still accessible via SVN. Another possible problem is that I would
need to be disciplined with my feature branches so that I do end up
making each commit to SVN too huge (but that is my own problem, haha).

Any comments and suggestions?

Thanks,
Eugene