[Numpy-discussion] DVCS at PyCon

[Neal Becker]

Ondrej Certik wrote:

> On Sat, Apr 11, 2009 at 11:44 AM, Neal Becker <ndbecker2 at gmail.com> wrote:
>> Ondrej Certik wrote:
>>
>>> On Fri, Apr 10, 2009 at 12:43 AM, Eric Firing <efiring at hawaii.edu>
>>> wrote:
>>>> Ondrej Certik wrote:
>>>>> On Thu, Apr 9, 2009 at 10:45 PM, David Cournapeau
>>>>> <david at 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 at 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/
> 

Why not try asking on mercurial at selenic.com (gmane.comp.version-
control.mercurial.general)