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

[Robin]

On Tue, Feb 24, 2009 at 12:28 AM, Andrew Straw <strawman at astraw.com> wrote:
> 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.

I guess this is getting slightly off-topic - also I'm not trying to
advocate anything over anything else (and don't have the experience to
do so!) but for the record I'm pretty sure what you say here about
bzr-svn is wrong.

Seperate bzr clones of the same svn repository *are* the same, and one
can merge between them. This works without bzr metadata in the svn
repo (simple example below). Bzr metadata is only needed to provide
the one-to-one mapping you mention, between bzr branches and svn
branches (for example, one can checkout from subversion using bzr-svn,
branch using bazaar, modify, and push back to a different location in
svn and it will be a svn branch). Bzr metadata is not visible if you
are running svn >= 1.5, and for other versions of svn whatever you are
using can be configured to ignore it (it is just svn properties as far
as I understand).

I know there are lots of arguments for/against the different DVCS's -
but I think the one thing bazaar is clearly ahead on is this svn
integration.

# two separate checkouts
jm-g26b101:tmp robince$ bzr co
http://svn.scipy.org/svn/scikits/trunk/mlabwrap mlabwrap-trunk
jm-g26b101:tmp robince$ bzr co
http://svn.scipy.org/svn/scikits/trunk/mlabwrap mlabwrap-trunk2

# branch each checkout
jm-g26b101:tmp robince$ bzr branch mlabwrap-trunk mlabwrap-branch1
Branched 93 revision(s).
jm-g26b101:tmp robince$ bzr branch mlabwrap-trunk2 mlabwrap-branch2
Branched 93 revision(s).

# add a file to each
jm-g26b101:tmp robince$ cd mlabwrap-branch1
jm-g26b101:mlabwrap-branch1 robince$ echo "a new file" > new.txt
jm-g26b101:mlabwrap-branch1 robince$ bzr add new.txt
adding new.txt
add completed
jm-g26b101:mlabwrap-branch1 robince$ bzr ci -m "add a new file"
Committing to: /Users/robince/tmp/mlabwrap-branch1/
added new.txt
Committed revision 94.
jm-g26b101:mlabwrap-branch1 robince$ cd ../mlabwrap-branch2/
jm-g26b101:mlabwrap-branch2 robince$ echo "another new file" > new.txt
jm-g26b101:mlabwrap-branch2 robince$ bzr add new.txt
adding new.txt
add completed
jm-g26b101:mlabwrap-branch2 robince$ bzr ci -m "a new file"
Committing to: /Users/robince/tmp/mlabwrap-branch2/
added new.txt
Committed revision 94.

# merge works fine
jm-g26b101:mlabwrap-branch2 robince$ bzr merge ../mlabwrap-branch1/
+N  new.txt
R   new.txt => new.txt.moved
Conflict adding file new.txt.  Moved existing file to new.txt.moved.
1 conflicts encountered.


Cheers

Robin