On Sat, Apr 11, 2009 at 11:44 AM, Neal Becker <ndbeck...@gmail.com> wrote: > Ondrej Certik wrote: > >> On Fri, Apr 10, 2009 at 12:43 AM, Eric Firing <efir...@hawaii.edu> wrote: >>> Ondrej Certik wrote: >>>> On Thu, Apr 9, 2009 at 10:45 PM, David Cournapeau >>>> <da...@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: 00changelo...@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 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
