[Numpy-discussion] DVCS at PyCon

David Cournapeau david@ar.media.kyoto-u.ac...
Fri Apr 10 03:07:46 CDT 2009

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

One big potential with the way git does branching is review - gerrit
(the code review tool used by Google for android) looks really nice.
Unfortunately, to see whether this is indeed true requires trying it,
because git-svn cannot be used to that effect (because of branches).

What would be great is to have git-svnserver, like git-cvsserver (which
is a gateway for cvs, that is people who don't want to bother can use
cvs to do as they do normally, and other people can use git proper). I
find it surprising that such a tool does not exist.

> It is possible that hg might 
> be a better fit--a better compromise--for present *and* *potential* 
> *future* contributors to numpy, scipy, and matplotlib.

Yes, that may be the case.

> Speaking to David: is git branch handling vastly preferable to both of 
> the branch styles available in hg?

Besides git, I am mostly familiar with bzr, which has the "branch is a
different directory" concept (but no named branches). I think bzr is
very confusing for advanced workflows in relation to this UI (I am too
lazy to restate my reasons, see here:

When I tried hg (version 0.8 maybe ?), there was little support for
named branches, but this has changed since I believe. When you have
different repositories for different branches, comparisons between
branches are difficult. This was the case in bzr. Is this the case in hg
? For example, can you log a subdirectory between two branches, easily
review files changes between branches/tags/etc... For the release
process, I find this very useful - but this can be somewhat alleviated
with git-svn without forcing anyone using it.

If people think that at least trying hg should be possible, I think it
should not be too difficult to have a hg mirror of svn - but I am not
sure whether you can use it to commit back to svn, like git-svn.


More information about the Numpy-discussion mailing list