[Numpy-discussion] DVCS at PyCon

[Eric Firing]

David Cournapeau 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

efiring at manini:~/programs/py/mpl/mpl_hgtestclone3$ hg up v0_98_5_maint
1957 files updated, 0 files merged, 90 files removed, 0 files unresolved
efiring at manini:~/programs/py/mpl/mpl_hgtestclone3$ hg up default
262 files updated, 0 files merged, 1785 files removed, 0 files unresolved

On my laptop, switching back and forth between the two active branches 
of mpl takes about 3 s for the first and 2 s for the second, timed by 
counting in my head.

> 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:

I'm on thin ice here, because for my own work I have not been using 
named branches.

>     - you can't remove them later, it is in the repository 'forever'

They can be removed with the strip command which is in the mq extension, 
but one must identify the root of the branch and supply that to strip. 
There may be some limits and gotchas.

>     - it is not easy to make them publicly available

Maybe I'm missing something, but I don't see this problem. For example, 
see http://currents.soest.hawaii.edu/hg/hgwebdir.cgi/matplotlib_mirror/
which is a mirror of the mpl svn repo using hgsubversion.  The branches 
are there, and show up when you clone it.  A problem is that the web 
interface does not allow one to select a single branch.  The log 
command, however, does.

For very lightweight local branching there are bookmarks, which allow 
one to make a local, changeable label for a given head within a repo. 
Again, such a local branch can be eliminated via strip--although I am 
not sure there is much point in doing so.  To go this route, I suspect 
one would first commit a tag, set the bookmark, make whatever changes 
and commits are desired, etc.  The point of the tag would be to make it 
easy to tell strip where to start stripping.

Certainly, hg is simplest when used as it was originally designed, with 
separate directories for branches.  How well it can emulate some 
git-style workflows, I don't know--probably never perfectly.  There are 
tradeoffs.  Overall, it appears to me that for someone who has never 
used a VCS, or for someone used to svn, hg has a lower barrier to entry 
than git.

> 
> One big potential with the way git does branching is review - gerrit
> (the code review tool used by Google for android) looks really nice.

How is the code review related to the branching options in git?

> 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:
> http://cournape.wordpress.com/2008/10/30/going-away-from-bzr-toward-git).
> 
> 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.

You can easily do diffs between changesets within a repo, regardless of 
whether they are on different named branches, and the diffs can be 
specific to a file or subdirectory.  Changesets can be identified by 
branchnames, tags, bookmarks, sequential numbers, or hash ID. For diffs 
between directories, there is an rdiff extension that is not distributed 
with hg.  I haven't tried it.  It seems like it should be standard--I 
have no idea why it has not been brought into the distribution.


> 
> 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.

svn interoperability is an area where hg has acknowledged lagging behind 
git-svn.  There have been several options.  What seems to be the best is 
hgsubversion, 
(http://www.selenic.com/mercurial/wiki/index.cgi/HgSubversion) which is 
what I am using to make the mpl mirror.  I haven't tried committing 
back, however--but it "should work".  Cloning does not maintain the 
connection to svn; the extra metadata is not propagated.

When/if VCS changes are made, I would prefer to see a clean break.  I 
think that all of the gateways are likely to be more trouble than they 
are worth.  For someone used to svn, doing the same basic operations 
with hg--but with the advantage of the full history on the local 
machine--just isn't that hard to learn.  (Yes, all the git proponents 
say the same thing, and maybe they are right--but I think it is a little 
harder.)

Eric

> 
> David
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion