[Numpy-discussion] DVCS at PyCon
Sat Apr 11 10:20:05 CDT 2009
On Sun, Apr 12, 2009 at 12:05 AM, Bruce Southey <firstname.lastname@example.org> wrote:
> On Sat, Apr 11, 2009 at 5:38 AM, David Cournapeau <email@example.com> wrote:
>> On Sat, Apr 11, 2009 at 6:52 PM, Gael Varoquaux
>> <firstname.lastname@example.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 <email@example.com> 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?
git <-> bzr works well for one time import, because they share a
common stream format for exchange. I don't know for hg (there is
hg->git, but I don't know the other direction - I used the convert
extension to try hg named branches from my git import of numpy).
> Rather can the selected system sufficiently support the other systems?
I think it would only lead to more complication, weird errors and
confusion. I know at least gnome thought about this, and quickly gave
> 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
It is exactly the same as before - there is a "reference" branch for
main development that people would use.
> Also, comments like 'get the
> latest version from the trunk' does become rather meaningless.
It is meaningless because there is nothing to do :) If you look at the
actual git mirror
The snapshot link gives you a tarball for every revision (this is not
specific to git, at least hg web portal has the same capability).
More information about the Numpy-discussion