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

[Ondrej Certik]

On Thu, Feb 26, 2009 at 7:11 PM, David Cournapeau <cournape at gmail.com> wrote:
> On Fri, Feb 27, 2009 at 8:21 AM, Pauli Virtanen <pav at iki.fi> wrote:
>> Thu, 26 Feb 2009 09:58:03 -0600, Travis E. Oliphant wrote:
>> [clip]
>>> The harm is the effort to do it.    Interacting with a web-page is
>>> slower than svn commit.   This extra step in the process does make a
>>> difference when you are time-crunched.
>>>
>>>> The problem with reviewing code after commit in trunk is that it takes
>>>> more effort to correct or ask about dubious points.
>>>
>>> I disagree with this statement.   Why does it take more effort than
>>> reviewing code on the trunk?    You can do an svn diff to get the code
>>> changes, and do the review exactly as you could with any other tool.
>>
>> I partly agree with this: if you want to immediately fix something
>> "wrong" in the suggested change yourself, a web-based code review tool
>> gets in the way. (But I haven't yet tried how well the command-line tool
>> would work...)
>>
>> But if you want to suggest some changes to the author of the commit, or
>> ask some specifics, the code review tool works fairly well as a
>> communication tool. Less hassle than commenting on a mailing list, and
>> more organized.
>>
>> I note that Github offers a similar "remarks-in-commits" feature. Could
>> be worth a try to check how this works in practice.
>>
>>> One way to see this is the difference between asking for permission or
>>> asking for forgiveness. Both have their place in social activities,
>>> but we shouldn't institutionalize one over the other.
>>
>> Another social aspect is that asking for permission has much more
>> positive connotations than asking for forgiveness.
>>
>> Anyway, difficult to tell how a mandatory review policy would affect
>> Scipy's development. I'd be reluctant to jump headfirst to requiring it,
>> without experimenting, even if Sage and Sympy have had good experience
>> about it. Nevertheless, I'm going to try to change my own workflow and
>> see what happens.
>>
>> [clip]
>>>> I've found git-svn quite good for maintaining topic branches. It can
>>>> switch easily between them using the same working tree, so that
>>>> compiles are fast, and editor just needs M-x revert-buffer.
>>>
>>> Thanks for the tip. At some point I may be able to invest some time in
>>> learning about git-svn. How do you switch between branches using
>>> git-svn.  With svn it's svn switch
>>> http://some-name-I-always-have-to-look-up-and-takes-time.
>>
>> Check what branches you have
>>
>>        git branch
>>
>> Check what branches other people have
>>
>>        git branch -r
>>
>> Switch working tree to a different branch
>>
>>        git checkout BRANCHNAME
>>
>> And it's fast. I think here Git beats SVN, Bzr and Mercurial in ease of
>> use. (Mercurial does have some similar features, but IMO they are a bit
>> less mature.)
>
> For me, that's one of the big killer feature of git. Switching
> branches is really cheap, both in time and in terms of command lines.
> When you add the ability to compare branches between them, git just
> blows away bzr.
>
> For example, when I want to get an idea of the development between two
> branches, I can do:
>
> git diff branch1..branch2 # --stat option is useful too to get a global view
> git log branch1..branch2
>
> In scipy, both of those takes less than a second, even for thousand of
> commits of difference. For release, of to make sure I merge what I
> think I am merging, this is very helpful. You just never do it with
> svn, because it is so slow (takes minutes) and the syntax to compare
> branches is awful. This alone is one of the reason why I vastly prefer
> git to bzr, too.

Exactly, and also git cherry-pick, to pickup some particular patches
from the other branch (e.g. some fixes etc.). Those are things that
really rock and once you get used to it, you never want to come back.

Ondrej