On Sat, Apr 11, 2009 at 6: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. > > 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 ? >
David, if your current git svn interface/workflow works well enough then I think we could move pretty slowly with switching to a dvcs. I updated my bzr and hg, with tortoise, (hg I haven't tried yet since it requires a computer restart) the svn support in bzr has improved considerably in the last half year, now bzr-svn uses its own svn bindings instead of pysvn. I checked out the scikits and scipy svn without errors with bzr. bzr-svn doesn't get stuck anymore on the end-of-line errors. And tortoise-bzr and the gui gbzr are easy to understand and are similar to svn in the presentation. I expect the new version of hg are the same, since the hg gui where already ahead last year and tortoise-bzr is an offspring of tortoise-hg. What is also very helpful in bzr compared to the git gui, are, for example, the explanations for different types of checkouts, branches or repositories are directly build into the windows for branching/checkout. mercurials two way support still seems weaker. According to the hgsubversion webpage the code is not "production ready". But, I haven't tried it out yet. But if both git and bzr support of local svn branches works well enough, then it is not so "urgent" that we switch away from svn. hg might still require a clearer break since it appears less interoperable with the other cvs. windows and gui support for git seems to be improving pretty fast, so it might be worth the wait. But the conceptional switch from file based to patch based interaction seems to be a big jump, that might always create some dissonance for those of us who think that code is a collection of files and modules and not a history of changes. Josef _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
