On Sat, Apr 11, 2009 at 5:38 AM, David Cournapeau <courn...@gmail.com> wrote: > On Sat, Apr 11, 2009 at 6:52 PM, Gael Varoquaux > <gael.varoqu...@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 <efir...@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 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion