[Numpy-discussion] DVCS at PyCon

Ondrej Certik ondrej at certik.cz
Fri Apr 10 04:54:15 EDT 2009


On Fri, Apr 10, 2009 at 1:07 AM, David Cournapeau
<david at ar.media.kyoto-u.ac.jp> wrote:
> Eric Firing wrote:
>>
>> This is simply wrong.  Mercurial uses hard links for cloning a repo that
>> is on the same disk, so it is faster and much more space-efficient than
>> copying the files.
>
> Yes, but maybe Ondrej talks about an older hg version ? Hg could not
> handle NTFS hardlink for some time, but it does now if you have pywin32.
>
> And still, switching between branches is faster in git than in hg, for
> some technical reasons I can't really explain (but can be found on the
> ML archives). But as I said previously, speed is not really an argument
> for me. If hg is fast enough for python, it is obviously fast enough for
> numpy and scipy. As long as it does not takes minutes to merge/review
> the 5 lines difference between two branches as is the case in svn right
> now, I am happier :)
>
>>  But if you do want named branches in a given repo,
>> you can have that also with hg.  Granted, it has not always been part of
>> hg, but it is now.  Same with rebasing and transplanting.
>>
>
> As I understand, and correct me if I am wrong, the problems with named
> branches are:
>    - you can't remove them later, it is in the repository 'forever'
>    - it is not easy to make them publicly available

Plus with git, you can fetch the remote repository with all the
branches and browse them locally in your remote branches, when you are
offline. And merge them with your own branches. In mercurial, it seems
the only way to see what changes are there and which branch and which
commits I want to merge is to use "hg in", but that requires the
internet connection, so it's basically like svn. I don't know if
mercurial has improved in this lately, but at least for me, that's a
major problem with mercurial.

But since python now moved to mercurial too, maybe they will help fix this. :)

It seems to me like the python distutils vs cmake discussion. I also
prefer the "unpythonic" cmake.

Ondrej



More information about the NumPy-Discussion mailing list