[Numpy-discussion] DVCS at PyCon

[Bruce Southey]

On Sat, Apr 11, 2009 at 5:38 AM, David Cournapeau <cournape at gmail.com> wrote:
> On Sat, Apr 11, 2009 at 6:52 PM, Gael Varoquaux
> <gael.varoquaux at normalesup.org> wrote:
>> On Sat, Apr 11, 2009 at 12:05:55PM +0900, David Cournapeau wrote:
>>> On Sat, Apr 11, 2009 at 11:53 AM, Eric Firing <efiring at hawaii.edu> wrote:
>>> No need to apologize, I think I used the work bashing inappropriately
>>> - I just wanted to say that the only way to understand the differences
>>> between the tools is to use them. Reading about them will only confuse
>>> you in my own experience. For example, I tried git once a long time
>>> ago (during an infamous discussion between git and bzr developers on
>>> the bzr M), could not understand a thing about it, and did not
>>> understand any point in it except speed. Then I was forced to use git
>>> because of bzr-svn constant frustrations - and I ended up to really
>>> like it.
>>
>>> At last scipy conference, I tried to "sell" git advantages to Stefan
>>> (a long time bzr user as well), who was far from convinced from my
>>> explanations and my ranting. Then later he used it and liked it. Of
>>> course, the logical conclusion could be that I am just very bad at
>>> explaining why I like git :)
>>
>> I am pretty convinced that git is an excellent tool, but it forces people
>> to invest a fare amount of time to learn it. I struggle quite a lot to
>> have people use _any_ VCS. I just whish they'd make a usability effort.
>> They could. There are a lot of low hanging fruits. But they don't care.
>> It is geeks programming for geeks, not for normal users, IMHO.
>
> But that's a development tool. I think it is expected that people have
> to somewhat learn something about it. I agree we should care about
> barrier of entry - if there is no way to make Josef happy, for
> example, that would be a really strong argument against git.

How good is the conversion between git, bzr and hg?
Rather can the selected system sufficiently support the other systems?

>
> But at the risk of being obvious, we should also care about people who
> work on numpy and scipy codebase on a quasi daily basis, no ?
>

There are at least two components:
1) Developers
2) Users like myself that test and use developmental versions and
provide the odd error report and patch.

Under the distributed approach, a developmental version does not
exist. Is there going to be a way to address this or will we have to
wait to release candidates to appears? Also, comments like 'get the
latest version from the trunk' does become rather meaningless.

Bruce