4 ms·

Why do you think mercurial branches are not lightweight? Which operation (create, close, push, pull) on branches is noticeably slower than git's?

by k_bx 13y ago

wtetzner 13y ago
I don't think he was talking about performance. I think he meant lightweight in the sense that a branch (in git) is just a pointer to a commit. It's conceptually lightweight.
- JoshTriplett 13y ago
  Both: it's conceptually lightweight, and because of that "pointer to a commit" structure it's also effectively free to create and move around branches.
  - k_bx 13y ago
    Why is mercurial branches ineffective to move around branches? If I'm not mistaken, if you want to move commits from one branch to another you do absolutely the same rebase.
- k_bx 13y ago
  Well, mercurial branch is just a record in list of branches, so is it then also "conceptually lightweight"? What is "conceptually lightweight" anyway?
fhd2 13y ago
According to #mercurial, branches (even closed ones) begin to noticeably slow down the repository when you reach around 2000. That's not at all impossible to reach with fine-grained feature branches. Bookmarks are really just pointers to commits, no branches in any sense, so they cannot be used for feature branches either. As a result, we simply don't use feature branches in Mercurial. It's literally the only issue I can think of.
- k_bx 13y ago
  Well, if that true, I'd prefer to investigate and make them fast, instead of using "bookmark-as-a-branch" because of all the cool stuff mercurial branches have (like great log-drawing with branch info).
- michal8181 13y ago
  Not true any longer. As described in http://mercurial.808500.n3.nabble.com/named-branches-vs-bookmarks-FUD-tp4006241p4006242.html http://mercurial.808500.n3.nabble.com/named-branches-vs-book... > We have users with thousands of named branches in production and have > done tests on up to 10k branches and the performance impact is fairly > minimal.

Why do you think mercurial branches are not lightweight? Which operation (create, close, push, pull) on branches is noticeably slower than git's?

by k_bx 13y ago

Why do you think mercurial branches are not lightweight? Which operation (create, close, push, pull) on branches is noticeably slower than git's?

wtetzner 13y ago

I don't think he was talking about performance. I think he meant lightweight in the sense that a branch (in git) is just a pointer to a commit. It's conceptually lightweight.

JoshTriplett 13y ago
Both: it's conceptually lightweight, and because of that "pointer to a commit" structure it's also effectively free to create and move around branches.
- k_bx 13y ago
  Why is mercurial branches ineffective to move around branches? If I'm not mistaken, if you want to move commits from one branch to another you do absolutely the same rebase.
k_bx 13y ago
Well, mercurial branch is just a record in list of branches, so is it then also "conceptually lightweight"? What is "conceptually lightweight" anyway?

fhd2 13y ago

According to #mercurial, branches (even closed ones) begin to noticeably slow down the repository when you reach around 2000. That's not at all impossible to reach with fine-grained feature branches. Bookmarks are really just pointers to commits, no branches in any sense, so they cannot be used for feature branches either. As a result, we simply don't use feature branches in Mercurial. It's literally the only issue I can think of.

k_bx 13y ago
Well, if that true, I'd prefer to investigate and make them fast, instead of using "bookmark-as-a-branch" because of all the cool stuff mercurial branches have (like great log-drawing with branch info).
michal8181 13y ago
Not true any longer. As described in http://mercurial.808500.n3.nabble.com/named-branches-vs-bookmarks-FUD-tp4006241p4006242.html http://mercurial.808500.n3.nabble.com/named-branches-vs-book... > We have users with thousands of named branches in production and have > done tests on up to 10k branches and the performance impact is fairly > minimal.