[SciPy-dev] The future of SciPy and its development infrastructure

[Andrew Straw]

Robin wrote:
> On Mon, Feb 23, 2009 at 10:59 PM, Andrew Straw <strawman at astraw.com> wrote:
>> Robin, can you point us to a public svn repo where non-trivial branching
>> is happening with bzr? I had lots of trouble trying to get anything
>> working in my attempts.
> I'm not sure what qualifies as non-trivial branching (DVCS people say
> all branching should be trivial!). I have only used it on my private
> repo myself, but I haven't had any problems. Asking on IRC, a good
> example is GNOME. Here are the developer branches created using
> bzr-svn
> http://bzr-playground.gnome.org/ - although it looks like they aren't
> pushing directly back to svn (but going through patches).
> 
> This is the best I could find documentating a workflow for using bzr with svn:
> http://www.serverzen.net/starting-with-bazaar-bzr-svn

Thanks for the links.

> But I think to avoid problems with merging the trick is to have a bzr
> checkout from svn as your sort of trunk branch, which you can then
> branch with bzr to create feature branches. Upstream branches can be
> pulled to the trunk branch, then merged to your feature branches, and
> when you want to push stuff back you merge it into your trunk checkout
> (which also commits it to svn). There are options to either push each
> individual commit as an svn commit, or just have a single merge commit
> in svn (the metadata for the bzr commits are there so they can be seen
> by other bzr users). Because all the metadata is in svn, you should be
> able to merge with anyone else who has their branch based on a svn
> checkout...

My problem when I tried this out was that the svn metadata wasn't the
same across different bzr repos cloned from the same svn repo -- thus no
ability to actually share the bzr branches between bzr repos. It sounds
like you have only tried this from a single bzr repo? Plus, I didn't
like polluting the svn repo with the bzr metadata, particularly given
this no-ability-to-create-the-same-bzr-clones issue. Git solves the
first issue (different git clones of the same svn repo produce the same
git repo) and thereby somewhat eliminates the need to store git metadata
in the svn repo. Which is why I like git-svn more than bzr-svn. But the
lack of one-to-one bidirectional mapping between DVCS branches and svn
branches it was prevents any of these schemes from working on any DVCS,
as far as I can see.