[Numpy-discussion] DVCS at PyCon

Ondrej Certik ondrej@certik...
Sat Apr 11 15:02:28 CDT 2009


On Sat, Apr 11, 2009 at 11:44 AM, Neal Becker <ndbecker2@gmail.com> wrote:
> Ondrej Certik wrote:
>
>> On Fri, Apr 10, 2009 at 12:43 AM, Eric Firing <efiring@hawaii.edu> wrote:
>>> Ondrej Certik wrote:
>>>> On Thu, Apr 9, 2009 at 10:45 PM, David Cournapeau
>>>> <david@ar.media.kyoto-u.ac.jp> wrote:
>>>>> Ondrej Certik wrote:
>>>>>> It is maybe easier to learn how to work with different clones, but
>>>>>> once you start working with lots of patches and you need to reclone
>>>>>> all the time, then it's the wrong approach to work, as it takes lots
>>>>>> of time to copy the whole repository on the disk.
>>>
>>> This is simply wrong.  Mercurial uses hard links for cloning a repo that
>>
>> On my laptop, recloning the whole repository (with hardlinks) takes
>> considerably longer than creating a new branch in the same directory,
>> that's a pure fact.
>
> You can clone a repo using:
> cp -al old new
>
> That should be very fast.
>
> As long as you then use an editor that behaves correctly with hard links.
> If you use emacs you can configure this behavior.

Ok, this seems to be pretty fast:

$ time cp -al sympy-git.hg/ new

real	0m0.129s
user	0m0.020s
sys	0m0.084s


e.g. this was the mercurial repo.

Creating a new branch in git:

$ time git co -b new2
Switched to a new branch "new"

real	0m0.048s
user	0m0.020s
sys	0m0.016s


is faster, but I agree, that 0.1s is not an issue for me. Is this
going to work on windows? I thought windows don't have hardlinks.
In any case, I would prefer to use standard mercurial tools for the
job, so if I do:

$ time hg clone sympy-git.hg new
updating working directory
566 files updated, 0 files merged, 0 files removed, 0 files unresolved

real	0m1.156s
user	0m0.948s
sys	0m0.164s


it still takes over a second. That's too much for me, as this
operation of creating new branches is something that I do almost all
the time.

The way out is to use branches in on repository, and imho that's the
correct way, both in git and in mercurial.

However, is here anyone who actually uses branches in mercurial? If
so, try this:

hg clone http://hg.sympy.org/sympy-git.hg
cd sympy-git.hg
hg branch new2
vim README  # do some changes
hg ci
hg up -C default
hg vi

and the hg vi doesn't even show your branch names and which branch
contains what.

let's edit README in the default branch:

vim README
hg ci

now if you do:

hg vi

it shows the new2 branch, and it shows the main branch diverged, so it
doesn't look as nice as in gitk, but it is possible to use. Now let's
try mercurial rebase:

$ hg up -C new2
$ hg rebase -d default
merging README
saving bundle to /tmp/ab/hg/sympy-git.hg/.hg/strip-backup/536215160a1c-temp
adding branch
adding changesets
adding manifests
adding file changes
added 2 changesets with 2 changes to 1 files
abort: 00changelog.i@536215160a1c: no node!


Oops, something went wrong. But commits are still there, so I guess I
can safely ignore the error message (could someone clarify?).

Now let's say I would like to merge the top two patches, since they
both modify readme and I would like to only send one patch. In git, I
just do "git rebase -i HEAD~2" tell it in vim which patches to squash
and I am done. In mercurial, it's a hell of a job:

$ hg qimport -r tip
$ hg qimport -r qparent
$ hg qpop
now at: 2146.diff
$ hg qfold 2147.diff
$ hg qdelete -r qbase:qtip

And I am still not done! I forgot to change the log (git asks you this
automatically during the rebase), so we need to import the patch to MQ
again:

$ hg qimport -r tip
$ hg qrefresh -e
$ hg qdelete -r qbase:qtip


And I am finally done. Now let's say some of the patches in MQ didn't
apply after changing the order or some other changes. Then I am in
deep troubles, because "hg qpush" fails and I need to modify the patch
by hand (that really sucks!). With git, you only use rebase, and
rebase is pretty powerful tool that can handle most of the conflicts
itself, and if it can't, it asks you to resolve it, I assume just like
mercurial rebase, but unfortunately mercurial rebase can't be used to
mangle patches or history.

I would like to ask mercurial proponents on this list to please
correct me above and do it the right way. :) So that it's not biased.

Also, read this nice article, that imho nicely compares git and mercurial:

http://rg03.wordpress.com/2009/04/07/mercurial-vs-git/

Ondrej


More information about the Numpy-discussion mailing list