[Numpy-discussion] Moving away from svn ?

David Cournapeau david@ar.media.kyoto-u.ac...
Sun Jan 6 01:20:50 CST 2008

Travis E. Oliphant wrote:
> David M. Cooke wrote:
>> On Jan 4, 2008, at 13:58 , Fernando Perez wrote:
>>> My vote so far is for hg, for performance reasons but also partly
>>> because sage and sympy already use it, two projects I'm likely to
>>> interact a lot with and that are squarely in line with the
>>> ipython/numpy/scipy/matplotlib world.  Since they went first and made
>>> the choice, I'm happy to let that be a factor in my decision.  I'd
>>> rather use a tool that others in the same community are also using,
>>> especially when the choice is a sound one on technical merit alone.
>>> Just my 1e-2...
>> +1 on mercurial. It's what I use these days (previously, I used darcs,  
>> which I still like for its patch-handling semantics, but its  
>> dependence on Haskell, and the dreaded exponential-time merge are a  
>> bit of a pain).
> I don't think it is time to move wholesale to something like Mercurial 
> or bzr.   I would prefer it if all of the Enthought-hosted projects 
> moved to the (new) system at once,  which is not going to happen in the 
> short term (but long term of course it's an open question).
How would you define short term and long term ? I understand the need to 
plan carefully things, and this takes time. But I am not sure I 
understand why not moving now, in the sense what will change in the 
future which will make the change better then than now ? I thought about 
targeting the change for 1.1, because it gives one precise time target, 
and gives use around 6 months, but this can be later if it takes more time.

I have not thought about all the details, but I had something like the 
following plan in mind:
    - first, importing the different trunks into the different contenders
    - making read-only mirrors of those import so that people can try it out
    - making tutorials so that people who do not know about the tools 
can start in a few minutes
    - Having a clear idea on the difference between the tools, and makes 
a list of the different requirements (speed, availability on platforms, 
3-party tools, GUI, etc...).

It seems mercurial is the tool of choice for almost everybody; I don't 
have any problem with that, except that I would like to see more 
arguments than just "I am using mercurial and it works" (the fact that 
most contributors knows mercurial certainly is an argument in favor of 
it, though). Having a list of requirements and how each tool fulfill 
each of them would be helpful, no ? I am certainly willing to do all the 
above for bzr, and it seems doing it for mercurial won't be any problem 
since so many people already know it.
> But, having an official mirror is a useful thing to explore.
> I suspect there are others with serious reservations about jumping off 
> of SVN just now (just when a lot of people have finally figured out how 
> to use it).
Using bzr is easier than svn IMHO, and knowing bzr, I knew how to use 
mercurial for basic things in 5 minutes (by basic I mean checking out 
code, branching, committing and getting patches):

bzr co http://bzr.scipy.org/bzr/numpy -> get the code
bzr st -> see the changes
bzr diff -> get a patch
bzr ci -> commit

Basically, you have to change svn to bzr :) And this is really similar 
in mercurial. Things like getting through the history, merging is a bit 
more complicated because there is no notion of global revision anymore, 
but this won't matter to most people ?
>   If there is an Hg mirror that allows other to use mercurial 
> at the same time then that sounds like a good idea to me.
Is it possible to get the svn dump for people willing to do the import 
(doing it from the import is not the only way, but is certainly the 
fastest) ? I can do the import for bzr; I can do it in mercurial too if 
nobody else jumps in, but since I am less familiar with mercurial, it 
would be better for someone else to do it.



More information about the Numpy-discussion mailing list