[Numpy-discussion] DVCS at PyCon
Fri Apr 10 16:16:22 CDT 2009
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@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@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
> - 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,
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
> 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:
> 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
(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
> Numpy-discussion mailing list
More information about the Numpy-discussion