Ondrej Certik wrote: > 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/ >
Why not try asking on mercur...@selenic.com (gmane.comp.version- control.mercurial.general) _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
